I'd really appreciate an answer to this, but can't afford a bounty (!).
Here we have a very simple GUI: the user just enters a source word and a target word in two text boxes, then presses a button. Then a lot of whirring takes place, and half a second later an answer is shown. The user goes on doing this until bored, then closes the app. Naturally, when the app restarts, the focus should be on the source, and I am hoping there is a neater way of achieving this than the one described. The commenter below has confirmed my feeling that the problem was an artefact of Lion persistence, which is a real nuisance in simple cases like this.
I set an NSTextField as First Responder (using the window's makeFirstResponder) in the awakeFromNib method of a simple 'controller' class, in a simple Cocoa application in Xcode 4.3, running under Lion.
The makeFirstResponder works fine the first time the app is loaded after reboot, but on every rerun the focus is set to the last field accessed. (I had tried connecting the window's initialFirstResponder outlet to the desired NSTextField, but got the same problem).
I fixed it finally by calling an initialisation function from the NSApplication delegate, and putting the makeFirstResponder call there.
The fix is a bit messy - I added a global variable to the controller, and initialised it to self in awakeFromNib.
I add the information that the Cocoa part of the app is simple, but the bulk of it is a mass of STL stuff in .cpp files, ported from Windows.
Deselect the "Restorable" check box in the attributes inspector for your window in IB. Of course, you then won't have the other behaviors you get with a restorable window like remembering its position and size.
Related
Summery:
I have a custom UITabBarAutoRotateController which returns YES from shouldAutorotateToInterfaceOrientation. This has no effect.
If I minimize and show the app again, the rotation issue goes away.
How do I refresh the screen so the user does not have to do this (so rotation works again)?
Details (setup graphically, so no code):
I have two UITabBarController in MainWindow.xib. I only want one to show at a time. So I am linking graphically rootViewController = tabBarController_name1. There is also tabBarController_name2.
I will also have an alert MessageBox for a user to choose what type of application they need, and it will choose a tab bar controller based on their request (per customer definition). This is commented out for now.
There is a bug with Rotation when two UITabBarControllers exist on the same xib. When I try to rotate the screen, it stays upward with wherever the main screen button (power button looking button) faces. HandleOrientationChange does not get called on the active custom ViewController being shown.
The reason I believe it's a bug is because if I hit the main screen button (minimizing the application), and click back on the application (brings it back to the foreground), rotation works perfectly!
Sorry for making you read all that mumbo :). My true question is, "Is there anyway I could refresh the main window or likewise UITabBarController's to get rotation working (without requiring the program be minimized and shown)"? A work-around, if you will?
p.s. I cannot use Storyboard for backwards compatibility reasons. The customer will be receiving this code/project. So I would like to keep this in one graphical page, rather than hiding/showing UITabBarItem's.
EDIT: two-uitabbarcontrollers-and-autorotation and uitabbarcontrollers-and-uinavigationcontrollers were both helpful, but did not address "why" this issue happens. "noob" here when it comes to xcode :)
Tab bar controller inside a navigation controller, or sharing a navigation root view is the answer. Do not use a TabBarViewController. Which, as a noob, I'm not quite sure why TabBarViewController exists (or at least isn't depreciated).
Dragging two TabBarViewControllers into the same page should result in a warning saying that you probably want to implement TabBarViewController by making a custom UIViewController and attaching a plain UITabBar to it.
Frustrating...but finally making progress :)
I'm trying to get a window I've created to accept files dropped onto it from the finder and all that happens when I try and drag a file onto the window is it snaps back to where it was on the desktop. Clearly I'm not setting something up right.
Inside the NSWindowController:initWithWindow: I'm doing:
[self.window registerForDraggedTypes:[NSArray arrayWithObjects:NSFilenamesPboardType, nil]];
I've tried putting this line in the view as well and no luck. What am I missing? Is there something I need to set in the .xib file as well?
Where do I need to put the -(BOOL)performDragOperation: function? Is that in my custom NSWindowController class? Is that what is failing?
Have you followed (or read) the documentation? The relevant section is titled "Receiving Drag Operations.
Most importantly, for a general view (or window), you need to implement -draggingEntered: as a first step and return the proper NSDragOperation (or at least not NSDragOperationNone) to "validate" the proposed drop. Without answering this, a drop won't even be allowed (so you'll never receive -prepareForDragOperation:, -performDragOperation: or -concludeDragOperation:).
Something else to consider: Do you really want the whole window to act as the dragging destination? More often, it's best to use a specific view that gives visual feedback to the user when -draggingUpdated: is called.
Unfortunately this is hard for me to test myself because I have yet to get a Magic Mouse of my own, but I've been told by my testers who do have a magic mouse that momentum scrolling isn't working in my app. I've not subclassed NSScrollView, but scrollview's document view is all custom. I have not overridden scrollWheel: anywhere, either, and yet momentum apparently just isn't working. I'm not even sure where to begin. I thought it'd just send scrollWheel events and things would take care of themselves. (Scrolling with a wheel or on the MBP trackpad works as expected.) Obviously I must somehow be doing something that's stopping it, but I don't even know where to begin. Thoughts?
I figured this out awhile ago and the problem was that on scroll, I was doing a lot of fancy view manipulation somewhat like how on the iPhone the UITableView adds and removes views as they scroll on and off screen. This worked great for performance - but the more I got into OSX programming, the more I realized this was wrong for OSX (but the right idea of iPhone).
Anyway, what's really going on, it seems, is that when you do something like a wheel scroll, the scroll event is sent to the view that's under the mouse cursor and then it ripples down the responders/views until it gets somewhere that handles it. Normally this isn't a problem, but with momentum scrolling the OS is really just sending ever smaller scrollWheel events to the view that was under the cursor at the time the momentum started. That means if the view is removed during the course of scrolling (because it scrolls off screen or something), it breaks the chain and the momentum stops because the view that's still getting the scrollWheel messages is no longer in the view hierarchy.
The "simple" fix is to not remove the view that got the last scrollWheel event - even if it's off screen. The better fix (and the one I went with) is to not try to use NSViews like they are UIViews and instead just draw the content using drawRect. :) Not only is that about a billion times faster, it Just Works(tm) with momentum scrolling because it's how OSX expects things to be done.
Repeat after me: OSX is not iPhoneOS.. :P
Odd scrolling behavior can occur when you don't set the Line Scroll and Page Scroll properties of the NSScrollView itself.
Beyond that, you're quite simply going to have to get a Magic Mouse - easily said or not :-) - to test this yourself or post the entire code of your custom view as well as the xib containing it. There's no way others can offer you more than guesses (like the above) without it.
Given an NSApp object (aka [NSApplication sharedApplication]), how can I get the currently active NSTextView, where the insertion point is blinking right now (if there is one)? :-)
I can go [[NSApp keyWindow] contentView] and try traversing the whole view hierarchy, but that seems too hard. Ideal code would be: [NSApp focusedTextView].
I tryed firstResponder for an app and a window, and also fieldEditor:forObject:, but this does not return anything interesting (at least, to me).
By the way, if anybody knows how to get the system wide current text view, that would be even cooler (Accessibility APIs won’t work: it won’t return a Cocoa NSTextView).
Thanks
The -firstResponder function returns the field editor. So if you want the real view you might need to check the first responder's delegate to get to it. Also see field editor for details.
There is probably no way to get it system wide as a NSTextViews since that object is in general in a different process space.
By the way, if anybody knows how to get the system wide current text view, that would be even cooler (Accessibility APIs won’t work: it won’t return a Cocoa NSTextView).
Not possible. NSTextViews are per-process; you can't get a proxy to an NSTextView from another process without that other process serving it up through an NSConnection. You're just going to have to use Accessibility.
On the bright side, using Accessibility means your app should (in theory) also work with Carbon apps that use MLTE/HITextView.
I have an NSCell subclass that I do all kinds of custom drawing in. The only time things seem to be entirely out of my control is when right clicking a cell to show the associated context menu. While showing it's context menu, the table (or cell - not sure which exactly is doing this) draws a focus rect. I would like to get rid of this, or at least find a way to draw my own version of it that better fits within my interface.
I have tried about 15 different methods that seem like they could give me control over this focus rect drawing itself (various first responder methods, various drawing methods, various highlight color methods, etc.), but I have yet to find something that changes anything about it.
Screenshot of the problem: http://twitpic.com/3zx2t
I am almost annoyed enough to class-dump AppKit and try to find whatever private method it's using to draw this annoying focus rect. Nothing else I do has any effect on it. Any help here would really save both my sanity and lots of future hair pulling.
Thanks so much!
Without completely overriding your table view's -drawRect: this is the only other way I know to get rid of the context menu highlight rect.
- (void)_drawContextMenuHighlightForIndexes:(NSIndexSet *)rowIndexes clipRect:(NSRect)rect {
return;
}
This is the method, used in Leopard at least, to draw the highlight around cells that will be activated upon by a context menu. It is unfortunately called directly by NSTableView's -drawRect: method and as far as I know there is no other way to signal your disinterest in having those highlights drawn.
Of course this is private API, it may stop working in Snow Leopard, or some other release. But at worst that means that somewhere along the way the context menu highlight may start up again in your programs on newer releases or some other functionality using this method may not work later. You have been warned.
On 10.5 and later, NSTableView allows you to bring up a contextual menu on any item in the table (that is, without having the side effect of changing the selection.)
It draws that 'focus rect' to indicate which item(s) are being acted on by the contextual menu.