I will like a HUD window to be only dragged around in my application and it can not go out of it. Is there anyway or any other component that will allow me to have a sub-window and not be able to be dragged out of the applications boundaries.
Thanks.
Your question is a bit vague but it sounds like you want to constrain a window's frame so that it is never outside the boundaries of another window.
To do this you'd need to make your HUD window a custom subclass of NSWindow. You would then override ‑setFrame:display: and call super's implementation, passing in the frame that you want the window to use.
Related
I'm using a NSToolbar and I'm trying to change the color to a white instead of the default gray. How can I accomplish that?
Since the toolbar integrates into the window title bar, you need to draw both the title bar and the toolbar. Which basically means you need to take over drawing for the entire window.
This requires "swizzling" which, while it works well, is not supported by Apple and therefore may get your app rejected from the app store.
Basically you need to inject your own code into the NSWindow class, by using objective-c runtime functions to modify the class definition. Note that this will affect all windows in your app, so you will need to have an if statement checking if this is a window you want to modify.
Subclass NSWindow, and in the +initialize method, find the "frame view" class which is the one that does most of the window drawing, and rename it's "drawRect:" method to "originalDrawRect:". Then you define a new "drawRect:" method on the class, as a duplicate of a method in your NSWindow subclass. This method should first call originalDrawRect and then do custom drawing on top of it.
Note: you will be drawing over the top of the window title text... so'll need to change the the drawing mode to kCGBlendModeColor or something. Or else just draw the title string again. You can ask the window where the title text should be drawn.
Here's a full article with more details: http://parmanoir.com/Custom_NSThemeFrame
I have an application that needs to display a window on top of anythings else. To achieve this I call [window setLevel:NSStatusWindowLevel] on my main window.
This works fine except that I can't use any modal dialogs or alerts from this window. The problem seems to be that [NSWindow beginSheet...] internally calls setLevel: on the target modal window with a value lower than NSStatusWindowLevel, so the modal dialog is displayed behind its parent window. The same happens when using an NSAlert from a window with higher window level, the alert is displayed behind.
The only [ugly] workaround I found is to inherit NSWindow, override setLevel: and prevent setting a lower level value on these modal windows but this only works when I have control over the window and doesn't work for NSAlerts.
Is there a more elegant solution for displaying modal dialogs from a NSWindow with high window level value that will also work with NSAlerts? Or I will be unable to use NSAlert with this approach?
one thing that comes to mind is to check if NSAlert uses a special NSWindow subclass you could make a category on it and hook the setLevel: method via swizzling (here is an example of extending an existing method via swizzling). there is nothing stopping you from doing this in a plain NSWindow subclass either.
I know its not the "elegant solution" you'd hoped for, but its the only one I know off the top of my head. I suppose it is slightly more elegant in that you don't have to insert your custom subclass everywhere throughout your program, but less elegant in that you are messing with the objective-c runtime using code that simply seems wrong.
I have a standard NSWindow with a toolbar. One of the toolbar's items is a custom view -- specifically, an NSTextField. (More specifically, it's a timer app -- the timer's controls as well as the digital display are all within the toolbar, with other stuff in the window's content area. The NSTextField is the digital display.)
Ordinarily, I just update the timer every second by changing the 'stringValue' property of the NSTextField, which causes it to update itself. But during a live window resize, even though the code that updates the 'stringValue' property is running (which I have verified with NSLog), the NSTextField doesn't draw itself again until the window resizing is done. Meanwhile, the stuff inside the content area is updating itself just fine.
I've tried all the ways I know to tell the NSTextField to draw itself, but it just refuses to happen until the live resize is done. Any ideas? Obviously it must be possible somehow, as the toolbar gets resized along with the rest of the window -- so you'd think it would be possible to force it to redraw one or more of its subviews as it is moving them around. I'm assuming I can hack this together by subclassing something, but my Cocoa-fu is not yet strong enough to figure out the easiest/most proper way to do so.
Thanks in advance...
EDIT: I kind of figured out a solution -- it's not great but it mostly works for now. It's in my comments below.
Just invoke -[NSWindow displayIfNeeded] after marking the view as needing display. I encountered this problem when implementing the Mac driver for Wine (an open-source project for running Windows software on OS X and other Unix-like OSes).
http://source.winehq.org/source/dlls/winemac.drv/cocoa_window.m?v=wine-1.7.11#L1905
(That's LGPL code, so you want to consider before copying it. But you can learn implementation techniques from it without worry.)
I think this should be a very easy one, but I cant find the answer on the docs.
I want to stop mouse dragging events which are in (or start in) my custom nsview subclass from causing the window to be dragged around the screen. How can I tell the window to stay still so i can interact with the view instead of dragging the whole window around? thanks.
In addition to the matter of whether you handle mouseDragged, you may need to override mouseDownCanMoveWindow to return NO, or override isOpaque to return YES.
You need to implement mouseDragged: in your view. As documented, NSView's implementation simply passes the message to the next responder, which means that it will end up hitting the window. (Why? See “The Responder Chain” in the Cocoa Event-Handling Guide.) Responding to the message yourself prevents that, as long as you don't call up to the superclass implementation.
I've wrote some small cocoa app and it's main window has HUD style.
The problem is - when I set HUD style Interface Builder automatically also sets Utility style - which make the main window topmost (always visible over every other windows). Is there a way to get HUD style panel/window but without making it topmost?
As it turns out - there's a pretty simple solution for my topmost problem:
[hudPanel setLevel: NSNormalWindowLevel];
Makes it act like a normal window that isn't topmost.
If you can't do it in IB, you'll have to do it programmatically. In this case, that means creating the window programmatically. (You'll want to move the window's views into a separate top-level view in the nib, and set that view as the programmatically-created window's content view.)
You should also file a bug report, as it doesn't seem from the NSPanel documentation that the HUD style necessarily implies the utility-window nature.