🚀 go-pugleaf

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

> So is there a way to determine id a given thread is a system thread?

As far as I know, there is no way to do that.

What exactly are you using AttachThreadInput() for?  Perhaps there is an
alternative approach.


Gambit

> What exactly are you using AttachThreadInput() for?  Perhaps there is an
> alternative approach.

I have an OOP COM server that is basically a 'client' for logging in/out of 
a propriearty system.  Calling the OOP 'Login' method calls 
ForceForegroundWindow() to ensure that the modal login form becomes the 
foreground, focused form.  Upon completion, the previous forground window is 
restored to the foreground with the same method.

I'm using code found frequently on these groups (slightly modified) to force 
a window to the foreground.  Currently I am using the following code:

bool __fastcall ForceForegroundWindow(HWND hwnd)
{
  bool Result;

  DWORD nullvalue = 0;

  DWORD ForegroundThreadID;
  DWORD ThisThreadID;
  DWORD timeout;

  if(IsIconic(hwnd))
    ShowWindow(hwnd, SW_RESTORE);

  HWND hForeWnd = GetForegroundWindow();

  if(hForeWnd == hwnd)
    return true;
  else
  {
 // Windows 98/2000 doesn't want to foreground a window when some other
 // window has keyboard focus
 if( ((Win32Platform == VER_PLATFORM_WIN32_NT) && (Win32MajorVersion > 4))
   || ((Win32Platform == VER_PLATFORM_WIN32_WINDOWS)
   && ((Win32MajorVersion > 4) || ((Win32MajorVersion == 4) &&
   (Win32MinorVersion > 0)))) )
 {
   // Code from Karl E. Peterson, www.mvps.org/vb/sample.htm
   // Converted to Delphi by Ray Lischner
   // Published in The Delphi Magazine 55, page 16

   Result = false;
   ForegroundThreadID = GetWindowThreadProcessId(hForeWnd, NULL);
   ThisThreadID = GetWindowThreadProcessId(hwnd,NULL);

   if(ThisThreadID != ForegroundThreadID && GetThreadDesktop(ThisThreadID) 
!= GetThreadDesktop(ForegroundThreadID))
   {
     if(AttachThreadInput(ThisThreadID, ForegroundThreadID, true) )
    {
      BringWindowToTop(hwnd); // IE 5.5 related hack
      SetForegroundWindow(hwnd);
      AttachThreadInput(ThisThreadID, ForegroundThreadID, false);
      Result = (GetForegroundWindow() == hwnd);
    }
   }
   if(!Result)
   {
  // Code by Daniel P. Stasinski
  SystemParametersInfo(SPI_GETFOREGROUNDLOCKTIMEOUT, 0, &timeout, 0);
  SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, &nullvalue, 
SPIF_SENDCHANGE);
  BringWindowToTop(hwnd); // IE 5.5 related hack
  SetForegroundWindow(hwnd);
  SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, &timeout, 
SPIF_SENDCHANGE);
   }
 }
 else
 {
   BringWindowToTop(hwnd); // IE 5.5 related hack
   SetForegroundWindow(hwnd);
 }
 Result = (GetForegroundWindow() == hwnd);
  }
  return Result;
}
//--------------------------------------------------------------------------- 

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

>    if(ThisThreadID != ForegroundThreadID && GetThreadDesktop(ThisThreadID)
> != GetThreadDesktop(ForegroundThreadID))

You are ot closing the desktop handles that you are retreiving.

With that sai, you can't attach to a thread to another thread in a different
desktop.  The documentation for AttachThreadInput() even says as much.

You shouldn't even be dealing with desktops to begin with, unless you are
writing your own service.  In which case, you shouldn't be showing a modal
form from a service anyway.


Gambit

> You shouldn't even be dealing with desktops to begin with, unless you are
> writing your own service.  In which case, you shouldn't be showing a modal
> form from a service anyway.

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."

Mark 

"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