Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
From one COM object to another one
Message
From
26/03/2000 00:20:50
 
 
General information
Forum:
Visual FoxPro
Category:
Classes - VCX
Miscellaneous
Thread ID:
00350435
Message ID:
00350493
Views:
29
Ed,

Understood. In that case I'd want to look at falling back to, say, a scenario where the actual usage of PhdBase was done not in an in-proc server. I really like the notion of having what I've learned to call "robot" computers that are unattended but have very specificly defined tasks they perform. Design them to scale and so forth.

In Michel's case perhaps he could find a way to use a solution like this - not the best for sure but if it works... - to give him what he needs.

Having a UI popup of any sort, as you know, is a definuite no-no for in-proc COM objects, and personally I would never use a UI for out-of-proc ones either.

So, if I follow my rules and PhdBase pops up a little message screen and there was no way around it I simply wouldn't consider using the product in the context of COM objects.

Now... Putting my old hacker's hat on.. I'd see if I could get me a disassembler like I've seen over the years and find where in the code the branch was to call that message... I'd put me a little jump in there or return or whatever was needed to simply bypass the issue. I know for a fact that someone like you could do something like that and even someone like me who really hasn't done a whole lot of assembly programming could probably find the specific location to ..er.. jigger the beast. *g*

Nothing like hacking an EXE. *g*

Really, all one needs to do is convince Jim to recompile the produt without that particular piece of code. My guess is he's burned out. He has been at this for a long long time.

Does someone else now have ownership or maintenance responsibilities for the product?

Best,

DD


>>Ed,
>>
>>Dunno, but unless & until Jim K. provides a fix anyone that uses the product is going to have to find something that will wouk in unattended mode.
>>
>>Now, not to argue with you that WSH is the end-all to be-all *g* but if either it or VFP can make it happen that's what counts for me at the end of the day.
>>
>
>Doug, my worry about PHDBase here wrt an in-proc server is the issue of what context the messagebox is being raised in - you need to direct a Windows message to get the messagebox to "Leggo my Eggo!", and let's suppose that I made use of PHDBase in a VFP in-proc server, perhaps under MTS, where there's no way to pre-fire the messagebox, and under MTS, nothing to sit and send the message indicating to PHDBase to sit down and shut up, especially if it's actually running on another distant system, which wouldn't be aware that PHDBase was sitting and waiting. This may preclude using PHDBase for VFP COM applications; it's not something I've explored. If PHDBase is something needed for a mid-tier component, especially one where deployment via MTS or another pool manager is an issue, and where there are I/O events that require an unusual intervention through a perhaps non-existant direct UI, this might make it imperative to either get PHDBase to fix the offending behavior or find an
>alternative tool that doesn't exhibit the objectionable and troublesome behavior.
>
>>Best,
>>
>>DD
>>
>>>>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*
>>>>
>>>
>>>I'd guess that the Wscript.Shell's SendKeys method could do it. I'd be worried about usability of PHDBase at all in an in-proc server because of this little issue. Maybe Rick Strahl has already seen it and has something in WebConnect to deal with this?
Best,


DD

A man is no fool who gives up that which he cannot keep for that which he cannot lose.
Everything I don't understand must be easy!
The difficulty of any task is measured by the capacity of the agent performing the work.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform