From VBA to Delphi conversion (Optional arguments issue)

calendar_today Asked Sep 26, 2016
thumb_up 12 upvotes
history Updated April 16, 2026

Question posted 2016 · +2 upvotes

At the moment I’m converting a project written in VBA to Delphi and have stumbled upon a problem with converting some Subs with Optional arguments. Say, there is a Sub declaration (just an example, actual Subs have up to 10 optional parameters):

Sub SetMark
    (x0 As Double, y0 As Double, 
     Optional TextOffset As Integer =5,
     Optional TextBefore As String = "",
     Optional Text As String = "",
     Optional TextAfter As String = "mm",
     Optional Color As String = "FFFFFF",
     Optional ArrowPresent As Boolean = True)

That Sub subsequently can be called like this:

    Call SetMark (15, 100,,,"135")
    Call SetMark (100, 100, 8,, "My text here..", "")
    'a lot of calls here

The Optional arguments are very flexible here, you can omit any of them, and you can assign a value to any of them as well. Unlike in Delphi.

Procedure SetMark
    (x0: real; y0: real, 
            TextOffset: Integer =5;
     TextBefore: ShortString = '';
     Text: ShortString = '';
     TextAfter: ShortString = 'mm';
     Color: ShortString = 'FFFFFF';
     ArrowPresent: Boolean = True);

It seems you cannot just make a copy of VBA call:

SetMark (15, 100,,,'135');// error here 

So, the question is: is there any way to convert that Subs to Delphi procedures keeping the same flexibility in parameters? My first idea was to use default parameters, but it doesn’t work. As for now it seems in Delphi I will have to pass all the parameters in the list with their values directly but that means a lot of work for reviewing and proper porting of VBA calls.

Any ideas?

Accepted answer +12 upvotes

Is there any way to convert the VBA subroutines to Delphi procedures, still keeping the same flexibility in parameters?

There is no way to achieve that – that flexibility to omit parameters, other than at the end of the list, simply does not exist.

For methods of automation objects, you can use named parameters, as described here: Named/optional parameters in Delphi? However, I very much recommend that you don’t implement your classes as automation objects just to get that functionality.

Whenever you switch between languages, you will find differences that are inconvenient. That is inevitable. The best approach is to try to find the best way to solve the problem in the new language, rather than trying to force idioms from the old language into the new language.

In this case you might want to use overloaded functions or parameter objects as ways to alleviate this inconvenience.

External references cited (3)

Top excel-vba Q&A (6)

+12 upvotes ranks this answer #45 out of 136 excel-vba solutions on this site .