🚀 go-pugleaf

"Mark Guerrieri" <mguerrieri@no_spam_verizon.net> wrote in message
news:44abc321@newsgroups.borland.com...

> I'm not dealing with other desktops.  My OOP server is just an EXE
> that runs in the context of the logged in user.  I only put that code in
there
> for error checking, since I have no control of who or what calls into the
> server, or from where.  I just have a method that shows a modal "login"
> form and needs to force its way to the forground, but which fails when
> called from within an Shell Namespace Extension.  As you said, the API
> states you should not AttachThreadInput to a thread in another desktop
> or to a system thread.  I put the test for other desktops in for the sake
of
> completeness, and now I am looking for a check for a "system thread."

There isn't any way to check for that (that I know of anyway - and you are
not the first person to ask for this).

The best I can recommend is to re-write your code to not rely on
AttachThreadInput at all (even better if you stop trying to force your
window to the front at all, which MS does not want programs to do anyway).
Otherwise, write a second version of your function that does not use
AttachThreadInput(), and then have the Shell Extension call that one instead
of the original version, which you leave for normal applications to call.

Alternatively, have the server trigger an event when it wants to display the
popup dialog, and have the application assign a handler to that event.  This
way, normal programs and Shell Extensions can assign different handlers that
are better tailored to their respective restrictions.


Gambit