[ wxwindows-Bugs-1824777 ] wxFRAME_TOOL_WINDOW style on wxMac

[SourceForge.net]

Bugs item #1824777, was opened at 2007-11-02 10:36
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109863&aid=1824777&group_id=9863

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: wxMac specific
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Robin Dunn (robind)
Assigned to: Stefan Csomor (csomor)
Summary: wxFRAME_TOOL_WINDOW style on wxMac

Initial Comment:
It woudl be nice if things like wxBusyInfo did not cause the parent frame of lose its activated look.  The wxFRAME_TOOL_WINDOW style should probably be updated to behave that way if possible.

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-11-18 19:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Stefan Csomor (csomor)
Date: 2007-11-04 13:51

Message:
Logged In: YES 
user_id=81467
Originator: NO

I couldn't find a corresponding style with no title bar and yet framed, so
I've made sure we just set the activation scope correctly to 'none' for
these windows, this results in the desired behaviour

Thanks,

Stefan

----------------------------------------------------------------------

Comment By: Stefan Csomor (csomor)
Date: 2007-11-02 13:09

Message:
Logged In: YES 
user_id=81467
Originator: NO

yes, this is the line I was referring to, I'll have to experiment and
check with the documentation to avoid causing havoc in the layering of
windows (probably two different classes will have to be used depending on
stay on top), but I'll do that soon

Best,
stefan

----------------------------------------------------------------------

Comment By: Robin Dunn (robind)
Date: 2007-11-02 12:58

Message:
Logged In: YES 
user_id=53955
Originator: YES

We already have this code in mac/carbon/toplevel.cpp:

    if ( HasFlag( wxFRAME_TOOL_WINDOW) )
    {
        if (
            HasFlag( wxMINIMIZE_BOX ) || HasFlag( wxMAXIMIZE_BOX ) ||
            HasFlag( wxSYSTEM_MENU ) || HasFlag( wxCAPTION ) ||
            HasFlag(wxTINY_CAPTION_HORIZ) || 
HasFlag(wxTINY_CAPTION_VERT)
            )
        {
            if ( HasFlag( wxSTAY_ON_TOP ) )
                wclass = kUtilityWindowClass;
            else
                wclass = kFloatingWindowClass;

            if ( HasFlag(wxTINY_CAPTION_VERT) )
                attr |= kWindowSideTitlebarAttribute ;
        }
        else
        {
            wclass = kPlainWindowClass ;
        }
    }

Woudl simply using something besides the kPlainWindowClass be the right
thing to do to implement this change?  If so, which class?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109863&aid=1824777&group_id=9863