String vs Asciiz

[Cliff Nichols]

I was working on a scheme where all my functions would return if an error occurred rather than each function return the results of the function (like a string) so I moved things that the parameter of the function was also a reply after the function.

Parameter as reply

FUNCTION GetClassNameId ALIAS "GetClassNameId"(ClassNameId AS string)EXPORT AS LONG
     ClassNameId = PROGID$($CLASS_GUID) + $nul
     msgbox ClassNameId
     FUNCTION = %FALSE
END FUNCTION

which works great that the reults of the function are returned, and if I want to know the string returned I just read it. But then testing in another language, for a string my only options are pointers to strings which does not work with a parameter, but if I go back to my old way

Reply as Reply

FUNCTION GetClassNameId ALIAS "GetClassNameId"()EXPORT AS STRING
     LOCAL ClassNameId AS STRING
     ClassNameId = PROGID$($CLASS_GUID)
     MSGBOX ClassNameId
     FUNCTION = ClassNameId
END FUNCTION

then the reply is correct

My only thoughts are that if I am forced to use a language then I need a different function for how the string is passed by that language? Unless someone has an idea for matching them all and not really care if it is a string, a pointer to a string, a string handle, or an asciiz or something else???

Unfortunately the other languages I have tested with do not know about pointers to strings, or asciiz (or blatantly hide it from me)

[Kev Peel]

Try this:

FUNCTION GetClassNameId ALIAS "GetClassNameId" (BYREF ClassNameId AS ASCIIZ, BYVAL nSize As LONG) EXPORT AS LONG
     ClassNameId = Left$(PROGID$($CLASS_GUID), nSize-1)
     FUNCTION = Len(ClassNameID)
END FUNCTION

The ASCIIZ buffer is provided with a size variable, so your DLL always knows how many bytes are available in the buffer. It also returns the length of the new string to indicate success. There is no need to add a NULL terminator as PB does this automatically.

Using ASCIIZ (byte array) pretty much guarantees compatibility with 99.9% of languages.

[Michael Mattias]

"Property ClassName "

????

Probably at the wrong point in the program (if you got this far you don't really need it anymore), but it's a thought...

[Michael Mattias]

ClassNameId = Left$(PROGID$($CLASS_GUID), nSize-1)
==>

ClassnameID = LEFT$(PROGID$($CLASS_GUID), _
                    IIF& (LEN( PROGID$($CLASS_GUID)) < nSize-1, _ 
                    LEN( PROGID$($CLASS_GUID)), nSize-1))

???

With all those literals (equates may as well be literals) in there it's probably not necessary, but were you working with ASCIIZ variables, you could not rely on ALL characters beyond the first $NUL also being $NUL and you could end up with a bunch of garbage at the end of your returned string.

[Kev Peel]

Huh? LEFT$ never goes past the end of the source string and PB always affixes a terminator when assigning a ASCIIZ string, so the code will always work fine as long as nSize is correctly set.

Use PEEK$ on the string, analyze the bytes and you can see what is written.

[Cliff Nichols]

?"Property ClassName "

best I could find was ClassnameProperty and only with OCX, (but then again I guess thats what I already eludeded to but

I was more looking at the why a parameter is handled differently than a reply from function???

(best guess yet is that I have to go back to the "Basics")

[Michael Mattias]

Oh, I was reading "PROGID$" as "$PROGID" .. that's different.

A single literal ("$CLASS_GUID") in the expression should not engender any of the difficulties posited.

[Cliff Nichols]

I think to avoid some confusion

ClassNameId AS string

could be ANY sort of variable as a string
and so could the function results

EXPORT AS STRING

The question being...why would the "Results" be readable and usable from any language, but the parameter as being a answer return as a "non-string" printable character???

I have several languages to keep happy (and yes I know verb-to-verb will not always work, but hoping to find a "User wants ACIIZ vs User wants StringHandle" to work with concept)

Maybe not possible...but if I can satisfy the 2 (possibly a 3rd situation) within PB and respond according to their language, would simplify things A TONNNNN (my initial attempts fail, but getting the feeling I know why both have a VarPtr, but only one has a StrPtr (but no clue as to how to test if the string pointer exists, but does it have a string handle???)

If I can figure that part out then I can tell if the "Parent" language handles pointers to strings or "StringHandles" and not have to write 2 functions exposed to that language

Odd thing is if the results of the function...they BOTH handle correctly

Hence why the difference between RESULTS and PARAMETER