[wx-dev] wxMac 2.8 - activate events and the menu bar

[Stefan Csomor]

Hi Yoav

that's the interim solution I would suggest to you, but this shouldn't 
be done for tool windows, only for documents

Best,

Stefan

Yoav Gonen wrote:
> Hey,
> I took another look at GetTopWindow and suddenly saw the first line,
> which somehow eluded me earlier.
> So the question is, why don't top-level windows call
> wxTheApp->SetTopWindow when they become active? I could do this in my
> own OnActivate event handler, but it seems to me like an inherent
> top-level window behavior.
> Yoav
>
>
> -----Original Message-----
> From: Yoav Gonen [mailto:YoavG at HumanEyes.com] 
> Sent: Tuesday, October 16, 2007 12:13 PM
> To: wx-dev at lists.wxwidgets.org
> Subject: [wx-dev] wxMac 2.8 - activate events and the menu bar
>
> Hello,
> I'm looking at src/mac/carbon/frame.cpp, line 211 (2.8 branch, I'm using
> 2.8.5) and I'm wondering: Why use wxTheApp->GetTopWindow(), and not get
> the "active" top level window?
>
> The long story:
> I have a sort of MDI application. I have an (invisible on Mac)
> wxMDIParentFrame-derived object, with wxMDIChildFrame-derived "document"
> windows as children. The parent frame has its own menu bar, which is
> visible when there are no documents open. The doc windows have their own
> menu bar.
> In addition I have a "tool" window, a frame which, unless explicitly
> closed, is always visible (like the layers list in Photoshop). As a tool
> window, it has the wxFRAME_TOOL_WINDOW flag set, and it does not have a
> menu bar associated with it.
>
> Say two documents are open, and doc window 1 is active. If I just click
> on doc window 2's title, a deactivate event is sent only to doc window
> 1, and an activate event is sent to doc window 2.
> If I now click on a menu item which opens a modal dialog (e.g. a file
> selection dialog), a deactivate event is sent first to doc window 2 (the
> active), then to the tool window. When the dialog is dismissed, an
> activate event is sent in the same order - first to doc window 2, then
> to the tool window.
> The problem is that in the wxFrame's OnActivate event handler, the frame
> changes the menu bar. The doc window sets it's own associated menu bar
> as the system's menu bar; the tool window, having no associated menu
> bar, searches for the first top-level window (by means of
> wxTheApp->GetTopWindow()) and sets its menu bar (if any) as the
> system's. However, the first top-level window might not be the active
> one, resulting in a menu bar which doesn't match the active window. This
> means that the next menu item callback, for example, will reach the
> wrong doc window object, and an action will be carried out for the
> non-active document.
>
> Thanks, and sorry for the long mail,
> Yoav
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wx-dev-unsubscribe at lists.wxwidgets.org
> For additional commands, e-mail: wx-dev-help at lists.wxwidgets.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wx-dev-unsubscribe at lists.wxwidgets.org
> For additional commands, e-mail: wx-dev-help at lists.wxwidgets.org
>
>   

-- 

Advanced Concepts AG  
Software-Engineering
Heldweg 10   
CH-8475 Ossingen
Switzerland

phone:+41 52 245 0 245
fax:+41 52 245 0 246   
http://www.advanced.ch
mailto:csomor at advanced.ch