Re: What is the equivalent Cocoa window level of Carbon kUtilityWindowClass?
On Jul 19, 2012, at 3:47 PM, Volker Schumacher wrote: I am working on a cocoa application that creates both normal cocoa windows and cocoa windows that are initialized with carbon windows. All windows should be floating above all applications. For the cocoa windows i set the window level to NSTornOffMenuWindowLevel, and for the carbon windows i use kUtilityWindowClass. Both works fine, windows are floating above other applications, but the problem is that carbon and cocoa windows don't have the same window level, so carbon windows will always float on top of cocoa windows. is there a way of giving both window types the same window level without loosing the floating above other apps? i guess since kUtilityWindowClass seems to the only window class which enables floating about other apps in carbon, i am looking for its equivalent in cocoa… Use an NSPanel and set it to be floating (-[NSPanel setFloatingPanel:]). If you must use a window level, I would think that NSFloatingWindowLevel be correspond to a utility window. (You'd also want to use NSUtilityWindowMask in the style mask.) Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
What is the equivalent Cocoa window level of Carbon kUtilityWindowClass?
Hi, I am working on a cocoa application that creates both normal cocoa windows and cocoa windows that are initialized with carbon windows. All windows should be floating above all applications. For the cocoa windows i set the window level to NSTornOffMenuWindowLevel, and for the carbon windows i use kUtilityWindowClass. Both works fine, windows are floating above other applications, but the problem is that carbon and cocoa windows don't have the same window level, so carbon windows will always float on top of cocoa windows. is there a way of giving both window types the same window level without loosing the floating above other apps? i guess since kUtilityWindowClass seems to the only window class which enables floating about other apps in carbon, i am looking for its equivalent in cocoa... thanks, volker ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: window level
Thanks, Matt and Paul, I will consider your suggestion to redesign my windows level. On Wed, May 26, 2010 at 5:47 AM, Matt Neuburg m...@tidbits.com wrote: On Tue, 25 May 2010 17:34:37 +0800, XiaoGang Li andrew.mac...@gmail.com said: For my application, there is a button in the modal window, if user click this button, I will open the helper book through NSHelperManager. Unfortunately, the helper window is ordered in the back of the modal window, I think this is not so UI-friendly What is not UI-friendly is your use of a modal window. Modal means the user can work *only* in *this* window. If that isn't you want, don't use a modal window. Or, when the user clicks the button, you should make the modal window close. m. -- matt neuburg, phd = m...@tidbits.com, http://www.tidbits.com/matt/ A fool + a tool + an autorelease pool = cool! AppleScript: the Definitive Guide - Second Edition! http://www.tidbits.com/matt/default.html#applescriptthings ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
window level
Hello, List,
Question about the window level. I will be so appreciated for any
comments.
There are three kinds of windows in my application: one modal window,
the window launched by NSHelperManager, and the font or color panel.
For my application, there is a button in the modal window, if user
click this button, I will open the helper book through NSHelperManager.
Unfortunately, the helper window is ordered in the back of the modal window,
I think this is not so UI-friendly. in order to put the helper book window
in the front of the modal window, I set the modal window level when the this
window become main or key:
-(void) windowDidBecomeMain:(NSNotification*) n
{
[myWindow setLevel:kCGNormalWindowLevel+1];
}
but this change cause another issue that, the font panel will appear in the
front of the modal window, when user click the font menu. So, do you have
any suggestion, I have tried other window level values defined, but all
failed to reach my goal, that making the modal window be ordered in the back
of the helper window, but ordered in the front of the others.
Thanks very much.
Andrew
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: window level
On Tue, 25 May 2010 17:34:37 +0800, XiaoGang Li andrew.mac...@gmail.com said: For my application, there is a button in the modal window, if user click this button, I will open the helper book through NSHelperManager. Unfortunately, the helper window is ordered in the back of the modal window, I think this is not so UI-friendly What is not UI-friendly is your use of a modal window. Modal means the user can work *only* in *this* window. If that isn't you want, don't use a modal window. Or, when the user clicks the button, you should make the modal window close. m. -- matt neuburg, phd = m...@tidbits.com, http://www.tidbits.com/matt/ A fool + a tool + an autorelease pool = cool! AppleScript: the Definitive Guide - Second Edition! http://www.tidbits.com/matt/default.html#applescriptthings ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
