Michel,

Dumb question here.... *g*

Since you know that PhdBase only shows that ugly little screen once, why not do something like this:

   if not thisform.HaveIEncounteredThatStupidPhdBaseBugYet
      if thisform.CheckToSeeIfThatDialogIsOnTop
         clear typeahead
         keyboard {"Enter"}
      endif
   endif

If your system goes down and then automatically starts then I'd just insert a call to a method/routine that forced a call to PhdBase, cleared the typeahead, manually entered something to clear the dialog and then proceed.

I'd even bet that Ed Rauh, George Tasker or someone else could provide you a routine that let you know whether or not that pesky dialog was on top and could ..er.. eliminate it. *g*

Just a thought.

Best,

DD (we do it the old fashioned way, we kludge it!)

>>>One COM object is calling another one. The method called in the 2nd COM is opening a table. When the call returns back to the 1st COM, the table opened is no longer in the scope. Is there any workaround for that?
>>
>>The datasession doesn't cross COM boundaries - if you need to share data between two COM objects, pass an ADO recordset.
>
>Have you ever tried that with PHDBase? :) I don't think it'll work. This relates to isolating the PHDBase process into a COM because of an actual problem of PHDBase. So, the object is to process the searches only. And, the actual syntax of PHDBase won't support that. Unless someone has found a way.