Create New Com Automation Class

[Michael Mullan]

 
// property Type
    { MethodType=Property DesignTime=False }
    Function ComType Returns Variant

Can we make the parser that creates Com Automation classes smarter? When a method returns an object reverence, all we see about it in the code is the fact that it returns a Variant. Can we get as a start the NAME or CLASS of object which is being returned as the variant?

Kinda like this?

 
// property Type returns QBStringType
    { MethodType=Property DesignTime=False }
    Function ComType Returns Variant

[Samuel Pizarro]

+1

[wila]

Michael,

Object reference? Do you mean interface dispatch?

If you return a variant in your ActiveX code then -obviously- it cannot return anything else.
A variant data type hides the actual data type, it can be any data type underneath as is seen in the DataFlex package variant.pkg
DataFlex cannot unhide that for you as it is dynamic.

If you're talking about an IDispatch interface then DataFlex will always return the same, like if it is an IUnknown interface.
Which ofcourse it is, but a derived interface.

In other languages, say for example VB6, you get the interface type and down there that is _incredibly_ handy due to dot notation.

Example in VB6:

Private Sub EdgeWebBrowser_OnNewWindowRequested(ByVal Args As AntViewAx.IAntViewNewWindowRequestedEventArgs)
  Dim URI As String
  Args.Handled = True
  URI = Args.URI
  EdgeWebBrowser.Navigate URI
End Sub

As you can see the parameter Args gets the data type interface AntviewAx.IAntViewNewWindowRequestedEventArgs

If you want to do the same thing as above in DataFlex then it looks like this:

First off this is what the class generates:

    { MethodType=Event }
    Procedure OnComNewWindowRequested Variant llArgs
    End_Procedure

"Variant" llArgs

If you then want to do what was a few lines in VB6 ...

    Procedure OnComNewWindowRequested Variant llArgs
      Boolean bIsComObjectCreated
      Handle  hoObj
      String  sURI
      If (IsComObject(llArgs)) Begin
        Get Create (RefClass(cComAntViewNewWindowRequestedEventArgs)) to hoObj
        If (hoObj) Begin
          Get IsComObjectCreated of hoObj to bIsComObjectCreated
          If (not(bIsComObjectCreated)) Begin
              Send CreateComObject of hoObj
          End
          Set pvComObject of hoObj to llArgs
          Set ComHandled of hoObj to True
          Get ComURI of hoObj to sURI
          Send ComNavigate sURI
          Send Destroy of hoObj
        End
      End
    End_Procedure

The problem here is DataFlex.
Even if you had the interface as a data type, you still would have to write a lot more code to do the same thing.

The good thing is that it is all boiler plate code, so it is easy to write once you've done it a few times.

The bad thing is that it is not easy to read and that DataFlex doesn't even follow basic rules on ActiveX like the automatic garbage collection (which is debatable)

edit: obviously this is also fine in VB6

Private Sub EdgeWebBrowser_OnNewWindowRequested(ByVal Args As AntViewAx.IAntViewNewWindowRequestedEventArgs)
  Args.Handled = True
  EdgeWebBrowser.Navigate Args.URI
End Sub

Sorry for making VB6 so complicated
--
Wil

[Michael Mullan]

Hi Wil,

As usual everything you said is entirely correct. Technically the process that creates all our boiler plate code has enough information to expand out the rest of the interface. But that’s probably an awful lot of work on and a lot of testing to be sure it’s doing it right. In the meantime I’d like it to give me back whatever reference is easiest to reach that tells me either the object name or the object type that the call is returning a reference to. I’m working on a QuickBooks interface right now, and they have a terrible habit of returning strings as a string object sometimes and other times as actually returning a string. They also have object wrappers for Boolean, integer, and so on. Being able to see some indicator of what class of object is being returned would make expanding out the boiler plate code so much easier because then we don’t have to go back-and-forth to the VB sample code or, heaven forbid, to their documentation.

/mm

[wila]

Hi Wil,

As usual everything you said is entirely correct.

LOL, in this house it is the wife that is always correct, not me!

Just trying to understand what you are asking for and what the benefit is.
Seems you are indeed talking about variant parameters of type dispatch interface.

If I go back to my example then you would like to see:

    { MethodType=Event }
    // Variant llArgs is of type AntviewAx.IAntViewNewWindowRequestedEventArgs
    Procedure OnComNewWindowRequested Variant llArgs
    End_Procedure

Possibly that line could be:

    { MethodType=Event }
    // Variant llArgs is of class type cComAntViewNewWindowRequestedEventArgs
    Procedure OnComNewWindowRequested Variant llArgs
    End_Procedure

as we then stick completely with the DataFlex linguistics.

and it would need to work for return type as well as parameter type.
--
Wil

[Michael Mullan]

Yep. Exactly that.

[Bob Worsley]

LOL, in this house it is the wife that is always correct, not me!

Wow, you learned that early!

[Vincent Oorsprong]

Wil,

The bad thing is that it is not easy to read and that DataFlex doesn't even follow basic rules on ActiveX like the automatic garbage collection (which is debatable)

What do you mean? AFAIK the only place where DataFlex does not free memory is when you use Alloc() but that is intentional. At COM level DataFlex increases and decreased the reference count for COM object automatically and it is up to the control to remove itself from memory and cleanup. When you have a variant variable with a VT_DISPATCH value and the variable it getting out of scope or when the variable gets a different value the reference count is decreased.

Can you give an example so that it can be further be discussed ?

[wila]

Wil,


What do you mean? AFAIK the only place where DataFlex does not free memory is when you use Alloc() but that is intentional. At COM level DataFlex increases and decreased the reference count for COM object automatically and it is up to the control to remove itself from memory and cleanup. When you have a variant variable with a VT_DISPATCH value and the variable it getting out of scope or when the variable gets a different value the reference count is decreased.

Can you give an example so that it can be further be discussed ?

The example is in the post you are replying to.
As I said, it is debatable.

You can't access an ActiveX interface from DataFlex without having to create a DataFlex proxy object.
In a strict technical debate, you are correct that DataFlex correctly keeps the reference count as it should.

In a more practical view.. that is all moot as you have to keep the reference count on your proxy objects by creating and destroying them manually.

Yes, you can re-use a proxy object in some cases, but the whole ActiveX interface is very clumsy compared to how it works in VB6 (in 1998!) or C#.
--
Wil

[Vincent Oorsprong]

Michael,

I agree this is very desirable and it would be high on my list too but AFAIK this information is not (always) available. When I open a COM module with OleViewer I never see what value to be used and thus what class should be used.