I have a static NSTextField that overlays a large error message in my OS X app. I'm trying to get it to allow the user to click controls beneath it.
In IB I've unchecked "enabled" and I've checked "Refuses First Responder"
I've also done it in code because that wasn't working:
[largeErrorText setEnabled:NO];
[largeErrorText setRefusesFirstResponder:YES];
Still, it is getting in the way of interacting with the objects below it. Any ideas what else it might be?
The only way I have found to make an object transparent to the click is to subclass that object (in your case the NSTextField) and override the hitTest method returning nil. This way that NSTextField will not respond to the click so the NSView below will respond to the click.
- (NSView*)hitTest:(NSPoint)aPoint
{
return nil;
}
I assume you are describing a scenario like the following image shows:
The inner red rectangle is the frame outline of the NSTextField label, and you're saying that even though you've disabled the text field and set refuses first responder, your clicks do not go through to the NSButton?
This design scenario describes a condition called "Overlapping sibling views". I would generally try to avoid this if at all possible. If you can't, you can get the desired behavior by making sure that the NSTextField label is "behind" all of the other UI objects that you want to be able to interact with. You can do that by selecting the label and choosing Editor > Arrange > Send to Back. That will assure that the button is in front of the text field so that it can properly intercept mouse events.
Related
Background: I have a custom derivation of NSTextField that I am trying to use as a cell in a grid similar to a spreadsheet.
I have set the nextKeyView of my NSTextField and am confused between two states that the NSTextField can have BOTH of which involve it having the blue focus-ring drawn around it:
the cursor is blinking in it => in this case the TAB key behaves as expected and moves to the nextKeyView and it is in a "text accepting" mode
it has not quite "entered" the text field for the purposes of text editing => the TAB key does not respond with KIC behaviour and move to the nextKeyView and trying to enter any text just in fact results in the following:
-[NSEvent key]: unrecognized selector sent to instance 0x60800012bf40
From background reading and a bit of debugging it appears that the first state corresponds to control/focus being handed off to the window's shared text editor and the custom NSTextField actually loses firstResponder status in this process.
What's interesting is how this differs from the behaviour of two standard NSTextField controls dragged onto an NSView in Interface Builder. Running such a simple app only the first state above is present at all as you tab from one NSTextField to the other! I am glad to have the intermediate second state in my app (because I need it) but I don't understand why it is happening...
Summary: two related questions
How do I programmatically control the NSTextField entering these two states of effectively accepting text and not while it has the focus [I do not know how to achieve this at all so this is my main problem...]
How can I get the KIC behaviour in the situation where the NSTextField has the focus but is not in "text editing" mode since this is the behaviour I am trying to get. [My current conclusion is that KIC does not work in this situation and that standard practise would be to resort to the regular overriding of keyDown for the set of keys that would normally be associated with KIC.]
I have a transparent NSWindow that follows the user's screen everywhere he goes (the NSWindowstays in front of every app, no matter what, even fullscreen apps).
In that NSWindow i have a mouseDown event that shows a popup. Let's say i'm on safari in fullscreen mode and i have my Window in front of it, i click on safari and i click again on my Window: nothing happens, the mouseDown doesn't occur. I have to click again so the mouseDown event is triggered.
How can i force my NSWindow to be always active so i don't have to click it 2x to trigger the mouseDown when i click on a background app and click in my window again?
Thank you!
I'm not sure if this is exactly what you want (it's not quite a window wide setting), but, from the documentation:
By default, a mouse-down event in a window that isn’t the key window
simply brings the window forward and makes it key; the event isn’t
sent to the NSView object over which the mouse click occurs. The
NSView can claim an initial mouse-down event, however, by overriding
acceptsFirstMouse: to return YES.
The argument of this method is the
mouse-down event that occurred in the non-key window, which the view
object can examine to determine whether it wants to receive the mouse
event and potentially become first responder. You want the default
behavior of this method in, for example, a control that affects the
selected object in a window.
However, in certain cases it’s
appropriate to override this behavior, such as for controls that
should receive mouseDown: messages even when the window is inactive.
Examples of controls that support this click-through behavior are the
title-bar buttons of a window.
Or you could try fiddling with
- (void)sendEvent:(NSEvent *)theEvent
and see if you can handle events in a custom way.
If you add a borderless NSButton instance to your window's view and set your image as the button's image (and as its alternate image, to make it more beautiful), it will work out of the box: Just connect the button's action method to your app delegate (or the object where you want to process the click action). A click on the image (i.e. the button) will then trigger the button's action method, no matter which window is active.
This worked for me, hope that will be helpful, This will keep your window always on Top of all applications
[self.window makeKeyAndOrderFront:nil];
[self.window setLevel:NSStatusWindowLevel];
I think what you really should do is use an NSPanel (a floating palette -- a special kind of NSWindow) that will do exactly what you want in a way that's consistent with the OS rather than trying to fight intended behavior.
Here's the NSPanel documentation:
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/nspanel_Class/Reference/Reference.html
And here's some helpful and pithy information:
http://cocoadev.com/wiki/NSPanel
By default, an NSPanel will disappear when the application is inactive, but you can turn this off.
I apologize for not laying it out more fully ... pressed for time.
Edit:
Note that you can probably get your window to behave as desired simply:
"The NSView can claim an initial mouse-down event, however, by overriding acceptsFirstMouse: to return YES."
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/HandlingMouseEvents/HandlingMouseEvents.html
You'll need to do this with any NSView subclass to skip the "activation click".
For some reson sometimes a NSTextField I'm using in Status Bar menu doesn't always allow me to input text. I click it and nothing happens as if it was disabled. Upon restarting program it works again. I don't do anything with it, it's just created in the interface builder.
That's because no NSWindow contains the NSTextField. The NSWindow sets the first responder when the window gets the main window. The NSStatusBar is global. It's never focused so your textfield only will be focused in the very beginning.
I'm not sure if there's a way to solve this problem in a nice way. You might try to set the first responder manually. You could also add a global event monitor
Example:
[NSEvent addGlobalMonitorForEventsMatchingMask:NSKeyDownMask handler:^(NSEvent* incoming) {
[textfield setStringValue:[incoming characters]];
}];
Note: This is a very bad way to fix this problem. I'd first try to set the NSTextField manually as a first responder if this is possible.
I am developing an interface for an OpenGL Simulation on the Mac using Interface Builder. All OpenGL stuff is being written in C++ (which I know fairly well). Unfortunately I have no idea about Objective-C.
Basically, I have a few NSTextField displaying info on an object selected on the Screen. Using these textfields the user is the able to manipulate the object on screen and then there is a Save Button and a Restore Button (which either save the new values or restore the original ones)
I have this all working. My problem is when I enter data into an NSTextField the "focus" of the windows seems to remain on the NSTextField (blue border remains around it).
I use the keyboard to interact with items within the NSOpenGLView, I need to pass the focus back to the NSOpenGLView when I hit either the Save or Restore buttons.
Sorry if this is a very straightforward question
Thanks
David
Have you tried using NSWindow makeFirstResponder method to make your NSOpenGLView the first responder?
Just managed to get it working.
I had to add the line:
[[NSApp keyWindow] makeFirstResponder: MyOpenGLView];
to the end of the function being called when I click on either of my buttons.
(Thanks Julio for pointing me in the right direction)
I want to show a total inside a toolbar. I put in IB the UILabel on top of the toolbar .
However, when I run the app, the UILabel is totally invisible (but can set values on code fine).
The most bizarre thing is that in other form, all work fine. I don't see why in one form work but not in another...
Any idea in how fix this? Or why is this behaviour happening?
Don't use a UILabel.
Use a UIBarButtonItem. Then set it to style: plain. It looks like a label, but it actually borderless button. This is the general practice of displaying text on a bar.
You can also create UIBarButtonItem with a custom view in code. You are simple "wrapping" the UILabel in a UIBarButtonItem allowing you to add anything you want to a tool bar.
To add in response to comment:
Either way, you make the button "inactive" and it doesn't respond to touches. Even though it is a button, it doesn't appear to be one. This is how Apple expects to add views to a toolbar/navbar as apposed to "float things on top of it". It violates no HIG guidelines, much the opposite, it is a reccomended design technique.
To stop the glow:
Create the button programmatically, make sure it is disabled, add it to the bar, it should then be disabled, but not dim.
In IB, have you tried to select the label and use the "Bring to Font" menu item (under Layout)? It seems like you are trying to do something pretty standard.
When you try to set values, is the label coming up as nil or at address 0x0? It's possible that the label is there, but its text cannot be set because its instance is faulty (not properly connected in IB to the IBOutlet).... Just put a breakpoint on the line where you are trying to set the value(s) for the label, and verify that the label variable is not nil (or 0x0). If it's not, try setting the text and verify on the next line that its text was set properly.
drag a UIButton into your UIToolBar. Then uncheck User Interaction Enables for this button.
Customize your UIButton so that it will look like a UILabel. Hope this will help you.