RE: SetForegroundWindow doesn't activate hidden main form / "Defau

I was wrong.

The problem had not been caused by some COM pointers. Instead, it was caused
by a bug in MFC's single instance code.

When looking for the application window (in AfxWinMain), MFC returns the
first HWND belonging to the respective exe name. This need not be the main
window, however.

The problem has been described on pocketpcdn before, I just didn't find it.
This article contains a bug-fixed version of AfxWinMain:
http://www.pocketpcdn.com/articles/mfc_command_line.html

The modified FindApplicationWindowProc() returns the first window with a
window text matching the application title (a plausible assumption on Pocket
PC).

--
Karl Traunmüller, CEO
Intumi Software
www.intumi.com




"Karl Traunmüller" wrote:

> Allright, problem solved.
>
> The problem was caused by un-Released() POOM COM pointers.
>
> Weird.
>
> --
> Karl Traunmüller, CEO
> Intumi Software
> www.intumi.com
>
>
>
>
> "Karl Traunmüller" wrote:
>
> > Hi all,
> >
> > this problem has been discussed before, but without resolution, so I'll
> > bring up the topic again.
> >
> > The situation is as follows:
> >
> > 1) I have an MFC application (eVC 4.0 SP3) for Pocket PC 2003 SE
> > 2) When I launch my application the first time, a main frame is created and
> > shown.
> > 3) I close the app with the close button ("X"), the main window
> > hides/minimizes.
> > 4) Now, If I launch the application a second time, it doesn't get activated.
> >
> > So, problem is, the application simply doesn't get activated from its
> > minimized state.
> >
> > If I try to launch the application a third time, the title bar text turns to
> > "Default Ime", but still no main window.
> >
> > MFC intercepts application activation in AfxWinMain, by means of a named
> > Mutex and an EnumWindows() run. If a running app instance is found, it is
> > activated with a call to SetForegroundWindow(), and the second instance bails
> > out again.
> >
> > I have debugged through all this, and everything loooks plausible, but the
> > call to SetForegroundWindow() has no effect for me.
> >
> > Remote Spy++ only showed messages up to (and including) item 3. The
> > application apparently didn't receive any messages after that. When closing
> > the main window, Spy++ showed this sequence of messages:
> >
> > (Message / WPARAM / LPARAM)
> > 0x0000036E (Unknown) 0 1E0BF3F8
> > 0x00000006 (WM_ACTIVATE) 0 0
> > 0x00000086 (WM_NCACTIVATE) 0 0
> > 0x0000001F (WM_CANCELMODE) 0 0
> > 0x00000005 (WM_SIZE) 1 010C00F0
> > 0x00000047 (WM_WINDOWPOSCHANGED) 0 22121FE0
> > (no more messages here)
> >
> > I have also investigated the situation with remote kernel tracker, which
> > shows behavior like this:
> > - the first app is launched, calls around a bit, and is put to sleep
> > - the second instance is launched, calls into shell32.exe, among other things
> > - the shell32 call calls back to the first instance (aha!), which then calls
> > into device.exe
> > - meanwhile, the second instance bails out
> > - the first instance lastly calls into NK.exe, and then doesn't do anything
> > more
> >
> > I can reproduce this behaviour consistently on an iPAQ 4150 (2003 SE), and
> > Pocket Loox 720 (2003 SE, VGA). Interestingly, activating the application via
> > System / Settings / Memory / Running applications works.
> >
> > Any help would be appreciated.
> >
> > Karl
> >
> > --
> > Karl Traunmüller, CEO
> > Intumi Software
> > www.intumi.com
> >
> >
.

Loading