>From: David Elliott <firstname.lastname@example.org>
>To: "Yue Huang" <email@example.com>
>Subject: Re: Re: Re:
>Date: Tue, 9 Dec 2003 23:29:13 -0500
>On Dec 9, 2003, at 10:41 PM, Yue Huang wrote:
>>----- Original Message -----
>>From: "David Elliott" <firstname.lastname@example.org>
>>Sent: Tuesday, December 09, 2003 12:44 AM
>>>You'll notice the code in that wxMac method sets the
>>>kFloatingWindowClass Mac style flag so long as a titlebar is going to
>>>be created somehow. This is a limitation of the Mac APIs. If you
>>>don't have a titlebar then you cannot have a real floating window and
>>>so it becomes a normal window. Real floating windows have quite
>>>different activation behavior from normal windows (they activate on
>>>switch to program and deactivate on switch away). I suspect what's
>>>happening is that your toolbar is getting an activate event when it's
>>>clicked which is causing the document window to be deactivated and for
>>>some reason the wxMac code isn't reactivating it properly.
>>I have tried wxFRAME_TOOL_WINDOW and wxTINY_CAPTION_VERT to set
>>kFloatingWindowClass. Now the toolbar gets proper activation when the
>>program starts. However, it is completely deactivated after I switch
>>applications and cannot be used any more. Another shortcoming is that
>>may move floating toolbar anywhere.
>>It seems to be a better idea to make the toolbar as a normal window if I
>>figure out how to reactive it after being clicked.
>Hmm.. I guess I'll have to take a look at this again. It was such a pain
>to get it working in the first place which I did for wx 2.4. I finally
>committed it to wxHEAD because people were complaining about the wxMac MDI
>and coming up with some strange solutions which didn't really address the
>problem and so I implemented mine which I believe to be theoretically
>correct but having a few implementation problems.
Yes. The floating toolbar behaves correctly within an application. I took a
look on the source code and found out why the toolbar remains inactive after
swicthing applications. Both activation and desactivation procedures are
bypassed for a floating window in MacHandleActivateEvent. It would be a
problem for switching applications since the floating window cannot receive
activation event, and consequently never be reactivated. I override
MacHandleActivateEvent to allow activation event go to the floating window,
and switching applications is not a problem any more.
With floating toobar, is there a way or an option to prevent users from
moving it anywhere, or place it back under menubar?
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
Please read http://www.wxwindows.org/mlhowto.htm before posting.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org