Wishlist: DefVar

[Torben Marcussen]

I know it is extremely inefficient but if working with COMs and you have to convert everything to Variants it would come in really handy if we could just set:

DefVar v

then we could use hungarian notation to assign our variants, Eg:

vText

Sure would save some typing
Just a suggestion for the next update....

[Steve Rossell]

Hi Torben,

You should look at PBWin version 9 and PBCC version 5. Both allow you to use COM Compatible data types and are automatically convert them to Variants for you. Also the new versions support direct V-Table interfaces as well as Dispatch. Lots of changes for COM support in the new versions since version 7.

[Torben Marcussen]

Thanks Steve.
Are you saying I no longer need to convert everything to variants..??

From the PBWin 9.0 COM samples:

LOCAL vText AS VARIANT
LOCAL vFileFmt AS VARIANT

vText = "Test.doc"
vFileFmt = %wdFormatDocument

oWordDoc.SaveAs(vText, vFileFmt)

It would be nice if I could just say:

oWordDoc.SaveAs("Test.doc", %wdFormatDocument)

Or even:

defVar v

vText = "Test.doc"
vFileFmt = %wdFormatDocument

oWordDoc.SaveAs(vText, vFileFmt)

Especially if you have to do the same thing for calls with multiple variant parameters.

Sure would save a lot of typing and development time..

[Steve Rossell]

From the PBWin 9 and PBCC 5 help file:

All parameters, return values, and assignment values must be in the form of COM-compatible variables. Literals and expressions are not allowed. COM-compatible variables include BYTE, WORD, DWORD, INTEGER, LONG, QUAD, SINGLE, DOUBLE, CURRENCY, OBJECT, STRING, and VARIANT. You should use caution passing string data since COM Objects assume that unicode format is used. When string data is contained in a VARIANT variable, conversion to/from Unicode is automatic, and no intervention is needed from the programmer. However, if you pass data in a dynamic string variable, you must use the ACODE$() and UCODE$() functions to convert the data to an appropriate format.

[Steve Rossell]

If you have PBWin 9 or PBCC 5, try this dispatch object that does not require variants. The values are automatically converted to variants by the compiler for you:

#COMPILE EXE
#DIM ALL

CLASS CMath
  INTERFACE ITrig
    INHERIT IDISPATCH
    
    METHOD ArcSin(BYVAL Value AS DOUBLE) AS DOUBLE
      METHOD = ATN(Value / SQR(1 - Value * Value))
    END METHOD
    
  END INTERFACE
END CLASS

FUNCTION PBMAIN () AS LONG
  LOCAL Trig AS IDISPATCH
  LOCAL Value AS DOUBLE
  LOCAL Answer AS DOUBLE
  
  Trig = CLASS "CMath"
  
  Value = .5
  
  OBJECT CALL Trig.ArcSin(Value) TO Answer
  ? "The ArcSin of "+FORMAT$(Value)+" is "+FORMAT$(Answer)

END FUNCTION

This could of course been written to use the faster direct V-Table calls, but I wanted to show a Dispatch interface using standard COM data types.

[Torben Marcussen]

I can see how that may come in handy, but...
I must be missing your point

How can that replace, or make it easier, to do what I have in my example..??

LOCAL vText AS VARIANT
LOCAL vFileFmt AS VARIANT

vText = "Test.doc"
vFileFmt = %wdFormatDocument

oWordDoc.SaveAs(vText, vFileFmt)

The reason for the request is that I have dozens of these and my code is starting to look like 70% declarations and 30% other code.

I have been away from PB for a few years and have just starting looking at it again after another member asked me for some help on an old example I posted years ago.

I agree the COM stuff has come a long way since V7. However with a few additions it could truely rival the MS equivalents ..

[Steve Rossell]

The differences in your code would be that vText can now be declared as a string and vFileFmt could be declared as a long. You do not need to cast them as Variants anymore. Also return values can be returned as a COM compatible data type instead of a Variant. This will save you from converting the returned Variants to it's native data type.

[Torben Marcussen]

That would be excellent if that could be done....
And worth the price of bread alone.

However, I tried it with the above example (from the samples folder) and by just changing the vText to a string I got a "Parameter mismatches definition" error when compiling. So I changed the .inc file from a variant to a string and it compiled OK but when I run it the program doesn't accept it.

Is there something else I have to do to make this work..???

[José Roca]

You could do it if the parameter was of type string of byval variant, but in the SaveAs method they are byref variants.