>>Hi Gang,
>>
>>Since my last project involved creating an in-process OLE Automation server, a couple of recent threads caught my eye. Basically, they confirmed that you couldn't have any sort of user interface coming from the DLL. However, since my DLL made several calls to the API (anybody surprised?:-)), an idea occurred to me.
>>
>>The VFP MESSAGEBOX() function maps directly to the Windows API function of the same name, it occurred to me that I might be able to access the API where I couldn't do it in VFP. First, I inserted a call to the VFP function, compiled and called the DLL. Sure enough, an OLE error occurred saying that I couldn't have any interface. I then added the following declaration:

>>DECLARE INTEGER MessageBox IN Win32API AS MsgBox;
>>  INTEGER hWnd,	STRING @lpText, STRING @lpCaption,;
>>  INTEGER uType

>>I then replaced the call to MESSAGEBOX() with MsgBox(), used zero for the window handle (the hWnd parameter), re-ordered the parameter list and re-compiled. It worked!
>>
>>Since I've rather limited experience with OLE Automation, I was wondering if anyone with more experience in this area might be able to tell me if this will perform as expected when the DLL is called from platforms other than VFP. If so, we might have the basis for, at least, an addition to the UT KB.
>>
>>Feedback? Comments?
>>
>>tia,
>
>
>Hi George,
>
>Glad this thread is still alive so I didn't have to search for it! I have a possible use for this capability - DEBUGGING! Passing error data back to the calling application and displaying can get to be a real pain especially if there are several layers. Might toy with this idea a bit when I get some time.

I've got a suggestion here - log your errors using a standard error handler to a file or DBF, and add a property to the exposed interface of the Automation object where you can put the name of the file and (in the case of a table) the record ID or record number of the entry that contains the error log. If an error occurs, the state of the OLE server at the time the error occurs now becomes available, and you don't have to kill the object unexpectedly server side - let the client examine the error log property to let you know something bad happened, and then graciously exit. If the object persists and you've been sneaky enough to add some interfaces where you can publish the state of the object for debug purposes, you may be able to examine the internal state of the object from a client-side debug session by invoking methods of the still-active, but mortally wounded, object. You can remove the debug interface when you've finished and are ready to ship; I normally leave the error log property in place to detect server side errors from the applicatiuon and log them in the client application's error log.

>
>Regards,
>Mike