Optional parameters in PB

[Daniel Corbier]

When defining a function or sub in PB with an optional numeric parameter, is there a way to differentiate between whether no parameter was passed as opposed to the value 0 being passed? For instance, I want my Sub to operate as follows:

Sub MySub CDECL ([Value])
If Value = 0 then ... (do something)
If (no Value) then ... (do something different)
End Sub

Or as an alternative, can you define a function with a default value? For instance, in VB you can define a function as follows:

Sub MySub(Optional Value = 1)

http://www.ucalc.com/dll

[Lance Edmonds]

No. because PB is a *true* compiler, there is no way for the code at run time to know how many parameters were passed. As a result, you need to send the parameter count as a parameter. Usually this is done with the 1st parameter, and the optional parameters following it.

--Lance.

[Francis Beaulieu]

If I retake the answer of Lance I will give to you an exemple:

SUB MySub (x AS Integer, [MyParameter AS Integer])


We must take it in the base that if MyParameter = 0 it is because we pass nothing in the parameter var.... Then 0 = nothing who care?IF MyParameter = 0 Then
Z% = 1 'Value by default
ELSE
Z% = MyParameter 'A reel value passed in the parameter
END IF


In the case where you want want to have a zero when it is really a zero, consider this test exemple:

IF MyParameter = 0 Then
Z% = 1 'Value by default
ELSEIF MyParameter = -1 Then
Z% = 0
ELSE
Z% = MyParameter 'A reel value passed in the parameter
END IF

I don't need a new parameter tralalala la...
But you will say, «If I want to test a true value too!».. Ok! Ok! OOOOOkkk!!!

Select case MyParameter
case 0 'Default value
Z% = 3734745

case -1 'Make a zero with it
z% = ???

case -2 'Make a True value with this one...
z% = -1

case Else
z% = MyParameter

End Select

[This message has been edited by Francis Beaulieu (edited 12-11-98).]

[This message has been edited by Francis Beaulieu (edited 12-11-98).]

[Daniel Corbier]

Thanks. However, this particular sub must have only one parameter. And I want that one parameter to be optional. Most of the time it needs to be used without the parameter as a command, such as:

DoSomething

Occasionally the programmer may need to pass a parameter. The thing is that for this sub, 0 does matter as a value, so that:

DoSomething

with no parameters will do a default activity that is different than:

DoSomething 0

where 0 means something. Is there perhaps an equivalent to VB's IsEmpty or Null or something, to check if the variable was not initialized?

I can easily work around this, but I'm simply trying to preserve the syntax of a DLL I've been selling that was previously compiled with VB.

Daniel Corbier,
UCalc Fast Math Parser, http://www.ucalc.com/dll

[Lance Edmonds]

Then I'd suggest always passing a parameter, but making the effective NULL parameter as %MAX_DWORD or something similar (ie, the largest + or - value the parameter will accept). I know that it will break your existing code, but there is no way around the problem of no parameter as the stack will corrupt if it tries to read a non-existant parameter.

Maybe Bob Zale or Dave Navarro will jump in here and provide a "good case" or suggest a solution.
My bet is that there is no solution that will not break your existing code.

--Lance.

[Brad Olson]

Having worked with the internals of some other languages that allow
optional params, the ones I've seen all pass a hidden param telling
how many real params are sent. So, IMHO, PB doesn't penalize us. It
just makes explicit what other languages hide.

--Brad

-------------
-Brad Olson
mailto:[email protected][email protected]</A>

[Lance Edmonds]

Correct. If I recall, the PB doc's explicitly suggest that you pass an additional parameter to indicate the number of "real" parameters you are passing.

-------------
Lance
PowerBASIC Support
( mailto:[email protected][email protected]</A> )

[Florent Heyworth]

Hi Daniel

I use pointers as an alternative to the VB empty keyword.
Something like:

%NULL=0

SUB DoSomething(MyParameter AS LONG PTR)
    IF MyParameter = %NULL THEN 
        CALL DoMyCodeWithoutOption()
    ELSE
        'it points to something real
        CALL DoMyCodeWithOption(@MyParameter)
    END IF
END SUB

Cheers
Florent



[This message has been edited by Florent Heyworth (edited December 10, 1999).]

[Daniel Corbier]

Thanks for the tip. The original question was posted a full year ago. I have since found a solution. Basically in the VB, C++, and Delphi include files for my component, I created wrap-around functions which allow optional arguments. Arguments are required for PB programs that use my component, but since the previous version of my component didn't support PB (it was ActiveX back then) this is not an upward compatibility issue.

Daniel Corbier, UCalc Fast Math Parser
http://www.ucalc.com

[Barry Erick]

But in PB you still can't do something without something to say the optional parameter is or isn't being passed. That means you can't do a

DIM WhoAmI CDECL ([workgroupname as string]) as string

 and allow someone to call in vb
 msgbox WhoAmI

 and 
 msgbox WhoAmI("shop")

 The first one would ALWAYS be
 msgbox WhoAmI(0)

which IS penalizing the user. I certainly hope PB can find a way to test for this. It seems something with a stack pointer check could do it, although if PB DLL passes the max number of stack pointers on each call, then that would not work unless looking into those locations for dumb stuff might find it.
It _IS_ Frustrating and all I need is a good windows debugger to see the actual machine code to try to figure a work-a-round. End of rambling

[Barry Erick]

Having a problem calling a function with an optional parameter from vb. In the vb ide, I get a error 49, bad convention when I do msg=mypbdll
It works fine if I remove the optional from both VB and PBDLL and pass a null parameter.

The declare has the alias and (optional na as string)
and I have tried the BYVAL also.

In PB the routine has function ... CDECL ([na as asciiz]) export as string

In PB, when I test it using the debug methings of compiling to EXE... it works fine. But I have tried ASCIIZ and String for the call and I can't get it to work.
Any tips on using susch a function from VB?

[Lance Edmonds]

VB does not support CDECL calling convention:

How to Call C Functions That Use the _cdecl Calling Convention
See MSKB Article ID: Q153586

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Daniel Corbier]

I posted the original question in this thread way back in
1998. But now that you have just resurrected the thread,
Lance, can the people at PowerBASIC please reconsider the
possibility of adding support for optional arguments in the
way that I described? Just this month, I was surprised to
see that my component (UCalc Fast Math Parser) was reviewed
in PB's BASICally Speaking. The review was very favorable
towards my product, but the documentation received lower marks
than the rest, because it gives examples for Visual Basic (along
with C++ and Delphi) but not PB. I want to give my component
better support for PB, but the exported interface for PB just
isn't as smooth as the one I have for VB (even though the DLL
itself is written with PB). Support for optional arguments
w/ default values is one example of something that can make the
PB interface more similar to the syntax I use in my
documentation.

The optional argument is not a runtime issue. The PB compiler
can resolve the function arguments when the code is compiled,
in such a way that if you define the following routine:

Sub MySub(Optional MyArg# = 1)
    ' DoSomething
End Sub

At compile time, the following line:

Call MySub

Would be resolved as:

Call MySub(1)

The optional argument would be for the programmer's convenience.
The actual compiled runtime would always be passed an argument,
whether it's a default argument or a user-given one. This does
not affect the efficiency of the runtime in any way.

By the way, in the other thread (entitled: ReDim At), I posted
some code for you to look at. Were you able to duplicate the
GPF error?

------------------
Daniel Corbier
UCalc Fast Math Parser
http://www.ucalc.com

[Lance Edmonds]

I'll pass on the request. I've not seen the code you referred too... I've been very busy for the past few days and not had much time to visit the BBS.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Scott Turchin]

Dumb question:

Dialog New 0, "My application",,,200,30, %WS_MINIMIZEBOX Or %WS_CAPTION Or %WS_SYSMENU Or %WS_EX_LEFT To hDlg


Note that After "My application" there are 3 nulls in there..


How does PB Do it? (Or is that internally classified?)


Scott


------------------
Scott
mailto:[email protected][email protected]</A>

[K Peel]

Or, how about a built-in function that returns the number of arguments that are passed to that particular function, such as NoArgs, that would be nice!

Regards,


------------------
Kev G Peel
KGP Software
Bridgwater, UK.
mailto:[email protected][email protected]</A>

[Lance Edmonds]

Scott:

Dialog New 0, "My application",,,200,30, %WS_MINIMIZEBOX Or %WS_CAPTION Or %WS_SYSMENU Or %WS_EX_LEFT To hDlg
Note that After "My application" there are 3 nulls in there..
How does PB Do it? (Or is that internally classified?)

There are only two nulls here, where the dialog origin would be expressed in dialog units. If you omit these two parameters, then the origin is determined by Windows, usually in a cascading fashion unless %DS_CENTER is specified. See DIALOG NEW for more info.

One interesting thing... you are using %WS_EX_LEFT which is an extended style, but you are using this in the 'normal' style position. In this case it has no effect because it's value is actually 0, but it raises an important point that I have seen other make before: using the wrong style equate can create unexpected effects and "bugs".
For example, using certain TEXTBOX equates for a IMAGEX control, etc.

Kev: The optional-parameter count has been requested before, but R&D told me (at the time) that there were some technical reasons why it was not implemented.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>