Parameter mismatches definition

[Michael Fitzpatrick]

Greetings! I just installed PowerBASIC. This is my first post. When I compiled the following code, I got the message: "Parameter mismatches definition". The compiler indicated that the problem is with the instruction:
xx = STR$(AddOneDbl,8). Your help will be greatly appreciated. May you have a blessed day.

Sincerely,

Michael Fitzpatrick

 
FUNCTION AddOneDbl ALIAS "AddOneDbl" (BYVAL x AS DOUBLE) EXPORT AS DOUBLE
  AddOneDbl = x + 1.0
DIM XX AS DOUBLE
 
  xx = STR$(AddOneDbl,8)
  MSGBOX "Current value of XX is: " & xx
END FUNCTION

Greetings again. I fiddled around with the above code (without finding my error), and got something strange(to me) which compiled without errors:

 FUNCTION AddOneDbl ALIAS "AddOneDbl" (BYVAL x AS DOUBLE) EXPORT AS DOUBLE
AddOneDbl = x + 1.0
DIM XX AS DOUBLE
DIM y AS DOUBLE
 
xx = 5.0
y = STR$(xx,8) > "tree"
 
END FUNCTION

I would have thought that there would be a type mismatch at the instruction: y = STR$(xx,8) > "tree"
but the code compiled without error. Why would there be no errors in the compile of the function AddOneDbl? Thanks again.

[Mel Bishop]

Looks like you need to change:

dim xx as double

to

dim xx as string

Welcome to the board!!!

[John Tate]

#COMPILE EXE

#DIM ALL

FUNCTION PBMAIN () AS LONG
DIM xx AS DOUBLE


  xx = AddOneDbl(8)
  MSGBOX "Current value of XX is: " & STR$(xx)


END FUNCTION
FUNCTION AddOneDbl ALIAS "AddOneDbl" (BYREF x AS DOUBLE)AS DOUBLE
  FUNCTION = x + 1.0
  END FUNCTION

This code seems to work. The function needs function /end function outside the of the calling main code. The function will return a double value, so I showed it in the message box with str$(xx)

Welcome to the PB forums. I don't know much technical stuff, but I have used PB win for several years now. I hope this helps

John Tate

[John Gleason]

I would have thought that there would be a type mismatch at the instruction: y = STR$(xx,8) > "tree"

It's not a type mismatch because STR$(xx,8) > "tree" is evaluated as a boolian true/false expression, in this case, 0, which is valid for a DOUBLE. That is: is " 5" > "tree"? " " is less than "t" so no, it isn't greater, therefore the value returned is 0.

[John Gleason]

FUNCTION AddOneDbl ALIAS "AddOneDbl" (BYVAL x AS DOUBLE) EXPORT AS DOUBLE
  AddOneDbl = x + 1.0
DIM XX AS DOUBLE
 
  xx = STR$(AddOneDbl,8)
  MSGBOX "Current value of XX is: " & xx
END FUNCTION

The problem here in addition to Mel's point, is that you are calling the AddOneDbl function, so it needs its parameter. Also you are calling it recursively ie. the function is calling itself, and would result an infinite loop. Probably it would GPF before it got to infinity.

So... this compiles, but I wouldn't recommend executing it:

FUNCTION AddOneDbl ALIAS "AddOneDbl" (BYVAL x AS DOUBLE) EXPORT AS DOUBLE
  AddOneDbl = x + 1.0
DIM XX AS STRING
 
  xx = STR$(AddOneDbl(99),8)    'I added 99 as the parameter
  MSGBOX "Current value of XX is: " & xx
END FUNCTION

[Michael Mattias]

>xx = STR$(AddOneDbl,8)

Simple explanation:

The function AddOneDbl expects exactly one parameter; parameters are passed to functions in parens; this code does not provide a param in parens, that is, passes zero parameters. Zero parameters passed vs one parameter expected = parameter mismatch.

[Michael Mattias]

FWIW, you will get the same "parameter mismatch" error by passing either a wrong datatype or a wrong number of parameters. (You can get a wrong number of parameters simply by typing a spurious comma)

A long time ago I sent in a NFS to separate these into separate errors, "Parameter Data Type mismatch" and "Incorrect number of parameters" but I guess that has not yet bubbled up into production.

MCM

[Michael Fitzpatrick]

Apparently function name cannot be treated as a variable

Greetings! I thank everyone who contributed to this thread. After a bit of head scratching, I came to the conclusion that neither the function name nor FUNCTION can be treated as a variable--they can only be returned. What this function was doing was after compiling the instruction AddOneDbl = x, it was then trying to treat AddOneDbl(which is the function name) as a variable which PowerBASIC does not allow. With this insight I maodified my code as follows which compiles and executes without error:

 
FUNCTION AddOneDbl ALIAS "AddOneDbl" (BYVAL x AS DOUBLE) EXPORT AS DOUBLE
  x = x + 1.0
  MSGBOX "Current value of x is: " & STR$(x)
  AddOneDbl = x
END FUNCTION

[Michael Mattias]

I came to the conclusion that neither the function name nor FUNCTION can be treated as a variable

???

Functions DO act just like variables in expresssions in assignments, except if the function requires parameters they must be supplied:

  LOCAL Z AS DOUBLE 

  LET  Z  =   AddOneDouble(2#) + AddOneDouble (2#) 
  PRINT       USING$ ("This better equal 4 : " #.##",  Z)

FWIW, I always use "FUNCTION=<returnval>" in lieu of "<functionname>=<returnval>"

Maybe that's just style, but if helps me find what the function is supposed to be returning when I have to debug it.

MCM