If you cannot register the DLL's, you cannot create COM objects. When you createobject, Windows checks to see if that exact (and case sensitive) module is available. A single DLL could contain any number of objects with any names, thus the need to register it.

OTOH there are DLL's which you can reference and instantiate via the DECLARE command. In that case you also need to know the proper name of the object to call. You might be able to determine that by using the object explorer on the dll. As part of the DECLARE command you will need to know whether the object returns string, numeric etc.

IOW by far the most practical way to incorporate DLL's is with the instructions/docs from the creator of the DLL's.

I am not sure what RBA you are referring to, given the number of companies and products named RBA. However as a side note, although I am not familiar with your product, it is highly doubtful that what you are doing is cost effective or has any benefits over your current VFP application.

>Hi Gang!
>
>Hate to bother you today.
>
>We have been told to recode our EZSIGN application (written in VFP 9.0 SP1). We have to use the RBA_SDK dll's to implement it.
>
>So..... we have tried various things to open the DLL and use it... like
>
>lo = CREATEOBJECT('rba_sdk.rba_api") to no avail.
>
>We tried registering the DLL but it will not load.
>
>So I've included a screenshot of the DLL being referenced in Visual Studio.
>
>Can you give some direction for us to implement it in VFP ?
>
>Thanks!