Looking for the 'VarType' function

[Edwin Knoppert]

It does not seems to exist, this may be handy.

Today i wanted tot test the parameter passed to a macro.
The vartype determines the action.

I only came up using a variant and determine it using the variantvt() call.
Not so bad but a more native function would be nice.

[Michael Mattias]

Not possible. Data cannot be identified as a "type" given only its contents.

That's why the compiler checks types in procedure header versus call line when compiling.

[Kev Peel]

Not possible. Data cannot be identified as a "type" given only its contents.

It most certainly is possible - at compile time the compiler will know the variable type of all standard variables (STRING, LONG, SINGLE, etc). So a simple MACRO like this could work:

MACRO SetInt(vVar,nVal)
  Select Case VarType(vVar)
         Case %VT_STRING ' Or whatever the compiler returns for STRING
              vVar = LTrim$(Str$(nVal))
         Case %VT_L4 ' Or whatever the compiler returns for LONG
              vVar = nVal
  End Select
END MACRO

Where "VarType(vVar)" is replaced by a numeric constant by the compiler upon compilation.

I can see this being useful in many "in code" situations where the type is ambiguous to the code being called. Of course, it will be no good for external or unknown variable types, external functions, and the like.

[Edwin Knoppert]

>Not possible. Data cannot be identified as a "type" given only its contents.
That's not the idea, mentioned a macro, the macro parameter is a known variable for the compiler.

[Michael Mattias]

>> Not possible. Data cannot be identified as a "type" given only its contents
>It most certainly is possible - at compile time the compiler will know ....

At compile time the compiler knows the type.

Even in your example, the type is known: it's a VARIANT!

[Michael Mattias]

You don't have to use a VARIANT to have a function which processes multiple data types, not knowing until execution time exactly what it is looking at...

Single Function to process any array type (CC3/Win7+) 12-17-03

.. instead of using a scalar variable, create a one-element array and call this function.

[Edwin Knoppert]

So?

That's for arrays.

[Edwin Knoppert]

This shows that any fixed type will become a double:

    Local i As Long
    Local w As Word    
    Local v As Variant    
    i = 1
    w = 2
    v = w
    MsgBox Str$( VariantVT( v ) )

At this time i can distinguish between variants and their types and the rest is a numeric (assuming long integer up to double).
It's good enough for me at this time but could be better.

[Michael Mattias]

So?
That's for arrays.

As I said, create a one element array before you make the call. If you want to pass "X" where X is "anything", you can instead ...

   X = some complex and no doubt brilliant piece of code. 
  REDIM Z(0) AS  (type of X) 
   Z(0) = X 
  CALL FunctionWhichDoesNotCareWhatTypeOfArray (Z())

Your 'FunctionWhichDoesNotCareWhatTypeOfArray' gets the data type and processes element zero.

No muss, no fuss, no bother. Piece of cake. Can of corn.

MCM

[John Gleason]

You might also consider adding another parameter to the macro, eg. an integer say 1 to 9, specifying all possible data types it might get. That would almost for sure be more efficient and faster because the calling code will know the type already (I think), so no calculation to determine type will have to be made by the macro (beyond eg. SELECT CASE).

[John Gleason]

>>Can of corn never heard that one before.

[jcfuller]

>>Can of corn never heard that one before.

Not a baseball fan?

A couple of possible sources of the phrase are cited in the definitive "New Dickson Baseball Dictionary." The most accepted: The phrase, first used in 1896, makes reference to a long-ago practice where a grocer would use a stick to tip a can of vegetables off a high shelf, then catch it in his hands or outstretched apron. Another possible source: Such a pop fly is as easy to capture as "corn from a can."

James

[John Strasser]

Obviously this is staying with arrays...

but there is the ARRAYATTR function

John

[Nathan Maddox]

Vartype....

If VARPTR() and STRPTR() could be changed to return 0
when variables AREN'T IN SCOPE....

Something This would be possible...

Code
#COMPILE EXE
#DIM ALL

FUNCTION VarType(OPTIONAL BYVAL vbyte AS BYTE, _
OPTIONAL BYVAL vINTEGER AS INTEGER, _
OPTIONAL BYVAL vLONG AS LONG, _
OPTIONAL BYVAL vDWORD AS DWORD, _
OPTIONAL BYVAL vCURRENCY AS CURRENCY, _
OPTIONAL BYVAL vString AS STRING) AS STRING


IF VARPTR(vbyte)<>0 THEN FUNCTION = "BYTE" : EXIT FUNCTION
IF VARPTR(vINTEGER)<>0 THEN FUNCTION = "INTEGER" : EXIT FUNCTION
IF VARPTR(vLONG)<>0 THEN FUNCTION = "LONG" : EXIT FUNCTION
IF VARPTR(vDWORD)<>0 THEN FUNCTION = "DWORD" : EXIT FUNCTION
IF VARPTR(vCurrency)<>0 THEN FUNCTION = "CURRENCY" : EXIT FUNCTION
IF STRPTR(vString)<>0 THEN FUNCTION = "STRING" : EXIT FUNCTION

END FUNCTION

FUNCTION PBMAIN () AS LONG
LOCAL A AS BYTE
LOCAL b AS INTEGER
LOCAL c AS LONG
LOCAL D AS DWORD
LOCAL E AS CURRENCY
A=1?
B=2%
C=3&
D=4
E=5
? VarType(a)
? Vartype(b)
? Vartype(c)
? Vartype(d)
? Vartype(e)
END FUNCTION

\code

[Kev Peel]

That is easily done by using BYREF for the parameters.

When new features are suggested like this, the goal is not for 'workarounds' but to determine if other users have a need for the feature as well. Judging by this thread, I'd say not many are interested or have a need

[Nathan Maddox]

I tried the BYREF before I posted and it would not compile...

It hung on ? VarType(b) with a parameter mismatch..

[Kev Peel]

The problem is that the OPTIONAL keyword does not mean the parameter must be completely skipped -- all parameters must be kept in order. ie.

? Vartype(a)
? Vartype(,b)
? Vartype(,,c)

..etc.

[Cliff Nichols]

Looks to me as..."Invalid Parameter" issue

sometimes the obvious is often overlooked

I found something similar (but no crash) between STRINGS vs ASCIIZ and passing a null (although still not sure if a CHR$(0), or $NUL or any other value that is unprintable.

I think in this case...are you expecting a pointer and passing a value? or are you expecting a value, and being passed a pointer???

Its a wicked picket when you inadvertently break the rules

[Kev Peel]

It's very clear as mentioned in my above post -- the compiler is expecting the BYREF variables as they are declared:

(BYTE,INTEGER,LONG,DWORD,CURRENCY,STRING)

Now, you can "skip" the parameters marked as OPTIONAL by leaving them blank, and the compiler will pass a NULL pointer (the function will see these params with VARPTR return code zero).

Valid (I'm not using var names to shorten the example):

FuncName(BYTE)
FuncName(,INTEGER)
FuncName(,,,,,STRING)

Invalid:

FuncName(,BYTE)
FuncName(INTEGER)
FuncName(STRING)

In brief: as long as the BYREF variables are explicitly declared, nothing short of a parameter override (BYVAL x) will satisfy the compiler's requirement of that parameter. A BYVAL parameter override when calling a function will let you pass whatever value you wish.

[Michael Mattias]

If VARPTR() and STRPTR() could be changed to return 0
when variables AREN'T IN SCOPE....

???

Your program will not compile if the object of VARTPR() or STRPTR() is not in scope.

(You might need to be using #DIM ALL to ensure that. But everyone uses #DIM ALL, don't they?)