06-20-2025, 06:31 PM
(This post was last modified: 06-20-2025, 07:16 PM by CookieOscar.)
Hmmm, in that case it is NOT to distinguish between 'by reference' or 'by value'...
but NOR is it distinguishing between 'a literal' or 'a variable' like you orginally asked!!
And NOR is it to checking if a parameter is static or not.
A parameter IS a variable, ALWAYS
And STATIC does not mean what you think it means, I think.
Also, a LITERAL is something you type yourself as parameter enclosed in quotes as the programmer during coding.
The moment you assign it to a variable name in code, or use it as a parameter in code, or let the user input something during execution it is... well, a variable...
So, now I think, what your actual question should have been is: how to distinguish between a variable and a variable?.
And as you can see... that is kind of a strange question. Which, at first, doesn't make much sense at all. Hence my confusion and trying to make sense of it
So.... there is absolutely no fool-proof and elegant way to solve your problem.... until optional parameters get supported by QB64.
The only possible, "kind-of", solution for now, is by adding a 'magic marker' to one of the parameters of your SUB.
The downside is, depending on what those parameters potentially can be, is that you could have a situation where the marker is the same as something the user has typed with that new input line. And in that case, again, you really can not know which is which.
So, if one of those parameters is always going to be of a certain fixed or maximum size, then you can add a marker to that parameter so it is bigger than it used to be in the normal 'old' circumstances.
eg.
If A$ in your original SUB is always only 1 character long, then you could add a marker to A$ so that it is longer than 1 character. The marker itself doesn't much matter in this case (can be a space, whatever). Or if A$ can be longer, but is still finite and thus has a known maximum possible length... simply make it so it is always longer than that maximum length... same principle. That would be the only sure way to make the difference. Not elegant, but it would always work.
But, if both A$ and CONTROLSTRING$ can have arbitrary unknown lengths, then you might have a situation where your marker is typed in by that user input!!! And then your SUB wouldn't be able to tell the difference again, you'd have a false positive. To circumvent that a little bit, you could make the marker as close as impossible to type as you can. Something like CHR$(0) + CHR$(1) + CHR$(2) + CHR$(3) or something rare and difficult to type (or an illegal unicode codepoint/pair as a wide character, but that might open a whole other can of worms as I don't know how QB64 acts with that).
I hope all this makes sense and helps.
It is very hard to explain without having access to the actual code in question.
That would make things A LOT more easy to show and explain.
but NOR is it distinguishing between 'a literal' or 'a variable' like you orginally asked!!
And NOR is it to checking if a parameter is static or not.
A parameter IS a variable, ALWAYS
And STATIC does not mean what you think it means, I think.
Also, a LITERAL is something you type yourself as parameter enclosed in quotes as the programmer during coding.
The moment you assign it to a variable name in code, or use it as a parameter in code, or let the user input something during execution it is... well, a variable...
Code: (Select All)
A$ = "this string will become a variable"
CALL MySub(A$, "this WAS a literal, and is now a variable in the sub")
PRINT A$ ' wil show "let's change A$ to something else"
'-------------------------------------------------------------------------------
SUB MySub(PARA_A$, PARA_B$)
PRINT PARA_A$ ' will show "this string will become a variable"
PRINT PARA_B$ ' will show "this WAS a literal, and is now a variable in the sub"
PARA_A$ = "let's change A$ to something else"
PARA_B$ = "you can do this, but it wont change anything"
END SUBSo, now I think, what your actual question should have been is: how to distinguish between a variable and a variable?.
And as you can see... that is kind of a strange question. Which, at first, doesn't make much sense at all. Hence my confusion and trying to make sense of it

So.... there is absolutely no fool-proof and elegant way to solve your problem.... until optional parameters get supported by QB64.
The only possible, "kind-of", solution for now, is by adding a 'magic marker' to one of the parameters of your SUB.
The downside is, depending on what those parameters potentially can be, is that you could have a situation where the marker is the same as something the user has typed with that new input line. And in that case, again, you really can not know which is which.
So, if one of those parameters is always going to be of a certain fixed or maximum size, then you can add a marker to that parameter so it is bigger than it used to be in the normal 'old' circumstances.
eg.
If A$ in your original SUB is always only 1 character long, then you could add a marker to A$ so that it is longer than 1 character. The marker itself doesn't much matter in this case (can be a space, whatever). Or if A$ can be longer, but is still finite and thus has a known maximum possible length... simply make it so it is always longer than that maximum length... same principle. That would be the only sure way to make the difference. Not elegant, but it would always work.
But, if both A$ and CONTROLSTRING$ can have arbitrary unknown lengths, then you might have a situation where your marker is typed in by that user input!!! And then your SUB wouldn't be able to tell the difference again, you'd have a false positive. To circumvent that a little bit, you could make the marker as close as impossible to type as you can. Something like CHR$(0) + CHR$(1) + CHR$(2) + CHR$(3) or something rare and difficult to type (or an illegal unicode codepoint/pair as a wide character, but that might open a whole other can of worms as I don't know how QB64 acts with that).
I hope all this makes sense and helps.
It is very hard to explain without having access to the actual code in question.
That would make things A LOT more easy to show and explain.
Who remembers QB30, GWBASIC, C64, ZX80?

