From VBA to Delphi conversion (Optional arguments issue)

The Problem (Q-score 2, ranked #198th of 303 in the Excel VBA archive)

The scenario as originally posted in 2016

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?

Why community consensus is tight on this one

Across 303 Excel VBA entries in the archive, the accepted answer here holds solid answer (above median) status — meaning voters are unusually aligned on the right fix.

The Verified Solution — solid answer (above median) (+12)

Advisory answer — community consensus with reference links

Note: the verified answer below is a reference / advisory response rather than a copy-ready snippet.

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.

When to Use It — classic (2013–2016)

Ranked #198th in its category — specialized fit

This pattern sits in the 96% tail relative to the top answer. Reach for it when your scenario closely matches the question title; otherwise browse the Excel VBA archive for a higher-consensus alternative.

What changed between 2016 and 2026

The answer is 10 years old. The Excel VBA object model has been stable across Office 2013, 2016, 2019, 2021, 365, and 2024/2026 LTSC, so the pattern still compiles. Changes that might affect you: 64-bit API declarations (use PtrSafe), blocked macros in downloaded files (Mark-of-the-Web), and the shift toward Office Scripts for web-first workflows.