Get that Data Type Discussion

[Cliff Nichols]

Often I find the need to check what data type is being passed to one of my functions, but only being able to check at compile-time and not Run-time.

Then I found some posts eluding to MCM's "PROCESSS_ANY_ARRAY.BAS"
and thought a pretty interesting concept for array's but still does not satisfy variables.

Then I thought of how much a pain it is to remember which value to use to get which reply from ARRAYATTR and set out to write a wrapper for it (I could swear I did one before, but got stuck somewhere, and could not find it, so I started from scratch)

Along the way I figured out how to do the same with Variables. So I can really see some potential for other projects that I do not know the data type until runtime.

I posted in the Source Code Forum under "Get that Data Type" for others to use.

[José Roca]

The method used in the function IsVariableDataTypeValue isn't realiable.

Try it with a WORD variable and it will return 3 (LONG) instead of 18 (WORD).

#COMPILE EXE
#DIM ALL

FUNCTION IsVariableDataTypeValue(BYVAL VariableName AS VARIANT) AS LONG
     FUNCTION = VARIANTVT(VariableName)
END FUNCTION

FUNCTION PBMAIN () AS LONG

   LOCAL x AS WORD
   MSGBOX STR$(IsVariableDataTypeValue(x))

END FUNCTION

[Cliff Nichols]

Good catch José,

I ran some more tests on other data types, and it would appear that "VariantVt" returns the 1st datatype it comes across that happens to match.

I have a few ideas to correct the issue, but may take a bit (unless this is a cause for a submittal to support ???)

[Michael Mattias]

Often I find the need to check what data type is being passed to one of my functions, but only being able to check at compile-time and not Run-time.

Call me a cynic if you will, but if this is "often" I think you need to rethink your program development strategy.

The advantage of using a strongly-typed or even moderately-strongly-typed (I made that one up) is that you can catch all data type mismatches at compile time. I for one like the fact the compiler catches most data type mismatches at compile time. (No it does not catch all of them!) (thru 8x anyway).

I assume here you are not referring to a "process anything passed" function, which is a horse of another color entirely.

And if it is, why not just use what you are using a bit more explicityly and write said functions with ..

FUNCTION Doesanything (V AS VARIANT) 
...
END FUNCTION

???

MCM

[Kev Peel]

Once you've mastered UNIONs and pointers, you'll find there is no use for variants outside of dealing with COM objects. They are not very efficient either

[Cliff Nichols]

Call me a cynic if you will, but if this is "often" I think you need to rethink your program development strategy.

Nahhh you're not a cynic, but in this case "often" means when a user writes code to interface mine, and say for instance they pass a "LONG" and I have it declared as "DWORD" (as it is documented).

As long as the user passes a value between 0 and 2,147,483,647 then they have no problems, as both LONG and DWORD fall in this range and both are 32 bits. But if passed a value outside that range (Roll the dice, new shooter, new shooter.....do you feel lucky???)

So in a case such as that, I would like to be able to catch type-Mismatches at run-time as best as I can, but like Jose pointed out, my 1st real try is not 100% (And who gets it 100% right the 1st time out???)

After a bunch of Google searches (which lo-and-behold all seem to come back to Jose's IT-Berator ) where I caught my 1st clue with VARIANTAPI and the underlying VARIANTDATA Union

Unfortunately I still can not catch why VariantVt returns the wrong data-type, but both VARIANTAPI and VARIANTDATA have the same values (oddly enough every element of VARIANTDATA is the same, Even when an invalid value for that data-tyoe)

So I think I know where VariantVt gets its value (but not how to fix it just yet)

Back to the ole drawing board with more ideas though

[Michael Mattias]

>when a user writes code to interface mine

I take it this is a DLL you provide?

If so, you are getting a 32-bit binary integer period and what the user calls it at his/her point of call is moot.

If you are providing a source code library to be #INCLUDEd, sounds like "user responsibility" to me.

For that matter, it sounds like "user responsibility" if you are providing functions in a DLL with some documentation and/or a header file.

I have got to be missing something.


FWIW, VARIANTVT gets its value from the underlying VARIANT structure (VARIANTAPI in PB-Supplied header files), vartype member.

MCM

[Cliff Nichols]

If so, you are getting a 32-bit binary integer period and what the user calls it at his/her point of call is moot.

If you are providing a source code library to be #INCLUDEd, sounds like "user responsibility" to me.

moot calls??? yeah, they may be moot, but they do happen.

and documented calls, yep I agree

sounds like "user responsibility" to me.

sounds like the same to me MCM, but you can NOT tell me you never had a user not change code to suit their language, and then claim it was "Your Fault" and not provide enough code to see if it was you or them doing something they claim they did not do? (Either of their own doing, or the compiler that compiled it)

The posted source code works (for the most part), but others have already pointed out flaws (and instead of ignoring them, I seek to fix them, unlike many examples I see in the www)

For WIW.....why the post of

FWIW, VARIANTVT gets its value from the underlying VARIANT structure (VARIANTAPI in PB-Supplied header files), vartype member.

Is it a prod at "I missed something in the docs???" or just a restatement of what I said??? because its the avenue I am researching, but can not find a MSDN on VARIANTAPI or other to even explain how the Type gets filled??? (Not to mention what *.h any are declared, but obviously both PB and MSDN use it, so it MUST exist somewhere)

Unless of course its another MSDN ("Do not look behind the curtain, the curtain may not exist in the future" type of calls?)

[Michael Mattias]

>but you can NOT tell me you never had a user not change code to suit their language

A. Are you providing source code, or a DLL with header files (documentation assumed in either case) for others to use?

B.

    LOCAL pV  AS VARIANTAPI PTR 
    LOCAL v    AS VARIANT 
    pV = VARPTR(v)

MS-supplied programming support materials refer to a VARIANT structure. However, "VARIANT" conflicts with the PB Keyword "VARIANT" so you have to use something else. PB-Supplied Win32API.INC uses VARIANTAPI.

[Cliff Nichols]

Jose's post of

The method used in the function IsVariableDataTypeValue isn't realiable.

Try it with a WORD variable and it will return 3 (LONG) instead of 18 (WORD).

Set me off to figure out why, and ask PB about help in the matter.

In short I was responded to as being able to pass the variable as a data type, but my tests failed. And being soooooo close, and yet unable to get it right I had to run tests of my own.

No matter the datatype, if passed to a function accepting a variant, then PB takes its best guess (in the case of byte vs word vs long, the return is a long), so I tried to test values (no good there because a byte will fit in a word, and a wod will fit in a long)

Has anyone got a better idea???

My other tests that I need to demo is if I declare a byte, but pass 65535 (well beyond byte values), then using VARIANT#(variable) returns 255

[Michael Mattias]

LET VariantVar =  value [b]AS datatype[/b] 

CALL Foo (VariantVar) 

FUNCTION FOO (V AS VARIANT)