Main window steals focus from child only when child is being moved
in [MFC]
|
From: Scoots on 9 Jun 2010 18:59 Okay, okay, so I know these groups are "dead" and MS isn't hosting them anymore. I don't care. You all always were more helpful than the forums. I have an MFC Doc/View application that is VERY atypical (It's actually an emulation of another system). But I have a window that controls the application that opens when you press ESC. All works fine. But if I try to move that child window, the main application steals focus after the window has moved ~10 pixels. I've commented out code, and I can't find it. I've tried using Spy, and I can see that the window is getting a WM_CaptureChanged (which is odd, since the window never used SetCapture). And WM_Killfocus. I have been unable to track down what's causing it. Can you all help me out with what to look for? I know this is vague, but what should I be looking for? SetWindowPos... what? This one seems simple, yet it's rather puzzling.
From: Tom Serface on 9 Jun 2010 19:29 Is the window a non-modal dialog? I wonder if there is a timer or something in the mainframe or view that is causing this to happen? Tom "Scoots" <linkingfire(a)msn.com> wrote in message news:bea9617b-b3cc-4245-a6ae-e17cb41e3a65(a)g19g2000yqc.googlegroups.com... > Okay, okay, so I know these groups are "dead" and MS isn't hosting > them anymore. I don't care. You all always were more helpful than > the forums. > > I have an MFC Doc/View application that is VERY atypical (It's > actually an emulation of another system). But I have a window that > controls the application that opens when you press ESC. All works > fine. But if I try to move that child window, the main application > steals focus after the window has moved ~10 pixels. I've commented > out code, and I can't find it. I've tried using Spy, and I can see > that the window is getting a WM_CaptureChanged (which is odd, since > the window never used SetCapture). And WM_Killfocus. I have been > unable to track down what's causing it. Can you all help me out with > what to look for? I know this is vague, but what should I be looking > for? SetWindowPos... what? > > This one seems simple, yet it's rather puzzling.
From: Brian Salmons on 10 Jun 2010 13:50 It is, and there are many timers. I disabled the ones I suspected, but it is entirely possible. After more testing, I found that it was only when I brought the window up via the ESC key. When selected from the task bar, it appeared and could be moved without issue. After pursuing this and trying to manually activate the thread (WM_ACTIVATEAPP) to mimic the messages I saw the task bar use, I finally just tried SetForegroundWindow. I had thought this wouldn't work, as the application was previously set to have it's parent as the desktop, but it does. I have no idea why, but I'm not complaining. Thanks! On Jun 9, 7:29 pm, "Tom Serface" <t...(a)camaswood.com> wrote: > Is the window a non-modal dialog? > > I wonder if there is a timer or something in the mainframe or view that is > causing this to happen? > > Tom > > "Scoots" <linkingf...(a)msn.com> wrote in message > > news:bea9617b-b3cc-4245-a6ae-e17cb41e3a65(a)g19g2000yqc.googlegroups.com... > > > > > Okay, okay, so I know these groups are "dead" and MS isn't hosting > > them anymore. I don't care. You all always were more helpful than > > the forums. > > > I have an MFC Doc/View application that is VERY atypical (It's > > actually an emulation of another system). But I have a window that > > controls the application that opens when you press ESC. All works > > fine. But if I try to move that child window, the main application > > steals focus after the window has moved ~10 pixels. I've commented > > out code, and I can't find it. I've tried using Spy, and I can see > > that the window is getting a WM_CaptureChanged (which is odd, since > > the window never used SetCapture). And WM_Killfocus. I have been > > unable to track down what's causing it. Can you all help me out with > > what to look for? I know this is vague, but what should I be looking > > for? SetWindowPos... what? > > > This one seems simple, yet it's rather puzzling.
From: Joseph M. Newcomer on 10 Jun 2010 14:17 See below... On Wed, 9 Jun 2010 15:59:23 -0700 (PDT), Scoots <linkingfire(a)msn.com> wrote: >Okay, okay, so I know these groups are "dead" and MS isn't hosting >them anymore. I don't care. You all always were more helpful than >the forums. **** At least today this group seems to still be functioning... **** > >I have an MFC Doc/View application that is VERY atypical (It's >actually an emulation of another system). But I have a window that >controls the application that opens when you press ESC. All works >fine. But if I try to move that child window, the main application >steals focus after the window has moved ~10 pixels. I've commented >out code, and I can't find it. I've tried using Spy, and I can see >that the window is getting a WM_CaptureChanged (which is odd, since >the window never used SetCapture). ***** That is irrelevant. The fact that YOU never wrote SetCapture doesn't mean it hasn't been called, for example, by the code in DefWindowProc that handles window dragging. You haven't said anything about this window, so we don't know if it is part of the MFC framework or not. When I want to have a "window that controls the app" in an MDI app, I create another doc/view pair, where the "document" is the application state and the "view" is the desired window. In fact, I often create a separate frame, so the close button doesn't actually close the window (my choice is to create this doc/view pair at app startup and it never goes away). But once you move outside the MDI framework, you are asking for trouble, and you seem to have found it. **** >And WM_Killfocus. I have been >unable to track down what's causing it. Can you all help me out with >what to look for? I know this is vague, but what should I be looking >for? SetWindowPos... what? **** What has happened is that by uncovering part of the window underneath the one you are dragging, you are causing it to do things in the redraw that, for example, redraw the caption bar. If you never did a SetFocus, then the focus didn't really change. So the caption bar is drawn with the correct focus it once had. Since you say you are doing a lot of unusual things, be aware that the MFC framework is not very programmer-friendly when you move outside its expectations. So I wouldn't at all be surprised if it is doing something to set the focus. MFC is convenient, but it makes a *lot* of assumptions about what is going on and how you are interacting with windows with the mouse and keyboard. Sadly, most of these expectations are difficult to determine except when they do something like you are seeing. **** > >This one seems simple, yet it's rather puzzling. **** No, it probably isn't simple, and as I said, once you start violating MFC's expectations, you are in for a *lot* of puzzling behavior. It isn't really puzzling; MFC is doing what it is *supposed* to be doing, given its set of assumptions. So I try very hard to not move outside the framework's assumptions. That way, madness lies. joe **** Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
|
Pages: 1 Prev: Possible to view TRACE output without VS? Next: Hello is vc.language group still in existance |