I like to create a Cocoa window without any chrome whatsoever. The only thing the user should see is what I draw.
I've discovered I can create a custom NSView but does this have to be in an NSWindow to display? If not, how can I display it without putting it in an NSWindow? If it does have to be in an NSWindow, how do I stop the window from drawing a title bar and other chrome?
Check out the sample:
http://developer.apple.com/samplecode/RoundTransparentWindow/index.html
I've discovered I can create a custom NSView but does this have to be in an NSWindow to display?
Yes.
If it does have to be in an NSWindow, how do I stop the window from drawing a title bar and other chrome?
Use NSBorderlessWindowMask when you create your window. (Assuming you aren't using a custom subclass of NSWindow, this means not creating the window instance in a nib. If you want to lay out your view hierarchy in a nib, do that in a top-level custom view, then load the nib and set that view as the window's content view.)
Related
I have an NSWindow and basically, what I am trying to pop up an NSWindow outside of the bounds of the NSWindow it's in every time a user hovers over the NSWindow.
But every time I try to do that, since the NSView is outside of the bounds of NSWindow it gets cut off.
Here's a picture of what I am trying to achieve:
You need to create a borderless NSWindow, large enough to contain your view, and make the window a child window of the main window it's attached to. To make a window a child of another window, you use the addChildWindow:ordered: method of NSWindow.
Child windows are attached to the parent window and will move with their parent window when the parent window moves. If you just open a new window without making it a child window, it will be "left behind" if the other window is moved.
To make a borderless window, pass NSBorderlessWindowMask as the styleMask to the initWithContentRect:styleMask:backing:defer: method of NSWindow.
The easiest approach is to create another NSWindow with no border and put the button in that.
I am using an NSWindowController not I want to set some attributes (specifically the styleMask property) on the window, before the actual window is shown. However, the window property on the NSWindowController is only available once the window is already on screen.
I could use initWithWindow: on the NSWindowController but then I am no longer able to use a nib file for the content of the window (because this uses initWithWindowNibName:.
So how can I configure the view before it is shown, something similar to viewWillAppear on NSView?
In Interface Builder, uncheck the ‘Visible At Launch’ attribute. When doing this, the window is not shown when the corresponding nib file is loaded by the window controller, so you can configure your window in -[NSWindowController windowDidLoad] and then manually show it using -[NSWindowController showWindow:].
Note that there’s no -viewWillAppear method in Cocoa.
I need to mark some opened window from my application. I can get the windows list, their system id, name, owner... Can I draw some NSImage only on choosen window?
If you have a window, as you say you do, you could add a NSImageView as a subview of that window. This NSImageView should be set to have a frame the same size as the window in question so it fills the window.
If you need to do custom drawing you could subclass the NSImageView and override its drawRect: method or you could just set its image property to an image that you have already created and added to the apps bundle.
Hope this is what you mean.
I have an application thad loads in plugins that have their own UI.
There is an IBOutlet called ContainerView in my AppDelegate.
When the plugin loads, it puts its own view (that is stored in a xib in the plugin bundle) into the Container view like so
[ContainerView addSubview:viewFromPlugin];
When the view loads, everything is fine but when I press tab the only controls that get any focus are ones outside of the ContainerView and none of them inside it get focus.
I've tried setting the container view as the initialFirstResponder and I've tried hooking up the nextKeyView from the last button in the tab order to the ContainerView.
Thanks.
I've tried setting the container view as the initialFirstResponder and I've tried hooking up the nextKeyView from the last button in the tab order to the ContainerView.
Is that what you want to do? Make the container view the key view? It doesn't sound like it; it sounds like you want the plug-in view (or a view within it) to become the key view.
This section of the Apple documentation explains all of the different aspects of the key view loop. I believe you'll want to either set the nextKeyView of the container view as well as the view before it, or override the container view's nextValidKeyView method—possibly both. You might also try setting the previous view's nextKeyView directly to the plug-in view's nextValidKeyView, skipping over the container view entirely.
Did you try calling the becomeFirstResponder method on your ContainerView?
http://developer.apple.com/iphone/library/documentation/UIKit/Reference/UIResponder_Class/Reference/Reference.html#//apple_ref/occ/instm/UIResponder/becomeFirstResponder
UIView classes inherit from UIResponder.
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.