Component Object Model support in AFL

Hi everyone.

I know, by AmiBroker documentation, that it's a better practice to avoid using the COM/ActiveX object of an outside language like javascript or Visual Basic etc ...
But I'm using an old application that uses some kind of OOP concepts that force me the need to use this option either way.
Now I tried following the instruction given by AmiBroker ( Component Object Model support in AFL - http://www.amibroker.com/guide/a_aflcom.html ) with one exception, I build the project ( using Visual Basic 6 IDE ) by File->Make option rather than run the IDE project, and then register that DLL using CMD with the regsvr32 command.
For my disappointment, AmiBroker couldn't recognize the given DLL and when I tried to retrieve a certain class from there, the result was getting a Null pointer.
Someone can help me please understand how I can make AmiBroker recognize my DLL.
Thanks in advance, Zack.

You can try two solutions:

  1. Visual Basic 6 generates 32 bit DLLs. You have to ensure that you are using 32 bit version of Amibroker.
  2. Try to register the VB6 DLL running CMD as administrator.

Hope this helps...

1 Like

There are many questions that arise because you have hardly explained anything.

From this

Are you trying to check it in the AB plugins window?
Because it won't show up there anywhere.

Secondly, it is apparent that you are trying to run your own COM server, in that case share the calling code. Also, did you test that your COM can be called from another application and that is working?

I've supposed that he's trying to use the VB6 DLL in his AFL code (not as a plugin), using the CreateObject instruction, because he's referencing the article "Component Object Model support in AFL"...

However, I'd like to be more precise in my previous answer: It's not necessary to register the DLL as administrator in the same machine your are compiling (because VB automatically does it on compile). But in that case it's necessary to run VB6 as administrator...

Thanks a lot !!! I didn't notice I got the 64-bit version installed, now it starts to respond.

If I may ask a little further on the subject, in the previously given link they recommend to switch
any function arguments and return values from all classes function into "Variant" type.

So I created a testing class to verify how it works and for some odd reason when I transfer a numeric value I get an error of Type mismatch. Isn't Variant variable can accept any type by default?

// DLL Class - AmiTest.DLL , Class1
public function TestMe(var as Variant) as Variant
TestMe = "Hello World , Number Given is " & var 
end function

// AFL file

// Code ......
tst = CreateObject("AmiTest.Class1");

hllo = tst.TestMe("1"); // Working Fine
hllo = tst.TestMe(1);   // Error 19. COM method/function call TestMe failed. Com error: Source: AmiTest Description: Type mismatch

And yet again, Thank you very much for your help.
Zack

Thanks but as LeoCV mention, I'm working with a VB6 code and I need the logic contained in this language. So I need AFL to recognize my VB6 code ( through the generated DLL ) and that's how AmiBorker instructing doing so with COM DLL.

I suppose that the first version of AmiTest.dll was something like this...

... and Amibroker is trying to use this (old) version. So, passing 1 (a number) doesn't works.

Try to unregister AmiTest.dll with cmd:
regsvr32 /u AmiTest.dll
... and recompile it again to ensure that Amibroker is using the "good" version...

1 Like

Hi LeoCV,
Thanks a lot, but that is not the case. I made a small testing DLL just for checking before I start to translate all the function signatures so AmiBroker could handle and use it. for some odd reason, any none array argument passed by AmiBorker is translated, by my DLL, as a "Single" type (I found it via the TypeName function ).
Thanks a lot, you direct me in the right direction over here.

You need to understand that OLE (i.e. Windows OS) would at least try to do type coercion by itself. For example if function expects string but you pass the number Windows OLE will change the number into string type (it is doing it internally behind the scenes via VariantChangeType https://docs.microsoft.com/en-us/windows/desktop/api/oleauto/nf-oleauto-variantchangetype ). Conversion single->double are also not uncommon.

But that coercion works ONLY if you declare parameters of your function NOT as "Variant" but as correct type.

2 Likes

Thank Tomasz,

I didn't even try leaving the functions signatures as they are because of the instructions that were given by AmiBroker themselves ( the link giving at the top ). Nonetheless, I will take it as you said about the OLE window auto-correction of the variables its given.