I've created an instance of NSObjectController (MenuObject on the image below) and method(test5:) for item's action there.
NSMenuItem is gray when I create a connection to First responder.
And it works fine when I create a IBAction directly.
I think it's because my NSObjectController(MenuObject) doesn't part of responder chain. No one can responds to selector and that's why item is grey. But how to fix it?
Thanks.
NSObjectController is a data-flow controller. Putting it in the responder chain does not make real sense.
However, you should read about the responder-chain for action messages. Doing so, you will prefer to put the action method into a window controller.
Related
I have to push a new segue when a button is pressed. But i also have an action attached to it that needs to be triggered before the segue is pushed.
Can you tell me how to separate them from each other? Any help would be appreciated.
Make the segue directly from one view controller to the other instead of connecting it to the button. Give it a meaningful name.
Then, in your button's action method, perform whatever you need to do first, then perform the segue using your view controller's performSegueWithIdentifier: method, using the meaningful name you chose earlier.
From your comments, it seems like you're trying to set properties on the view controller that is about to appear from your segue. If this is the case, you should implement prepareForSegue:, and use segue.destinationViewController to get a pointer to the view controller that is about to appear.
I am using the UIMenuController on a custom UIView subclass. This means it can become first responder, and claims it canPerformAction on the "delete" action.
I would also like this view's superview (also a custom UIView) to be able to use the menu controller, so on that superview, I have marked it as being able to be first responder, and implemented canPerformAction for different actions ("copy" and "cut" in this case).
Here's the thing-- when I make the menu visible from the (first) subview, it puts all three actions in the menu: delete, copy, and cut. In the debugger, I see canBecomeFirstResponder and canPerformAction being invoked on both views before the menu appears.
What's going on here? Why isn't the menu controller restricted to the view that's become first responder? Or am I not diagnosing this correctly?
Thanks.
What code are you using?
In the documentation for canPerformAction:withSender:,
This default implementation of this method returns YES if the responder class implements the requested action and calls the next responder if it does not. ... Note that if your class returns NO for a command, another responder further up the responder chain may still return YES, enabling the command.
It seems to be contradictory, saying the default implementation recurses up the responder chain, but then also that UIMenuController recurses up the responder chain if you return NO.
The easiest fudge is probably to override -nextResponder to return nil, but that might have other side-effects (for one, actions with a "nil" target go up the responder chain by default!).
Basically i wanted to implement a popup UIView so i followed what was posted here
POP-UP UIView "IMDB App" style
This works very well. However i have one query. My main view is a tableView. so when a view is popped up i disable scrolling in the table. Now when the popup subView is removed, i need to re-enable scrolling. How do i achieve that? i can't use willRemoveFromSuperview because the popup view is loading a different NIB altogether.
Should i use Notifications?
hope i was clear with explaining the scenario.
Thanks in advance!
Feloneous Cat has the correct answer. This is the perfect use a #protocol in your popup view along with a registered delegate. Something is triggering that popup view to close. Whatever that trigger is, call the protocol and the delegate can handle the situation as needed.
Furthermore, when protocols are used correctly, your code becomes very reusable within a project as well as in other projects.
What you could do is subclass UIView and override removeFromSuperview to send a notification. I don't think there's ever a case where a view gets removed without using the removeFromSuperview method.
in my iphone app one event (touch up inside UIButton) is connected to three actions in different classes. The first action creates a game object, the second pushes the a new view controller and the third triggers an method in the pushed view controller.
On interface builder I wired these actions to the event in the order mentioned above but the app crashes sometimes when I press the button.
Does some body know if the order in which I wired the action on IB will be maintained at runtime in my device and others?
I'd guess that the order in which actions are called is not guaranteed to be the same order in which you wire them up in IB. Consequently, your app might be trying to configure the view controller before it creates it. You can verify the calling order by putting an NSLog statement in each of your action methods.
Even if the actions are called in IB order, that's a code maintenance nightmare; imagine coming back later to insert a new action in your UIButton and needing to remember the order in which you originally wired them up.
Solution: To enforce order, create a single IBAction method that calls the other three methods in the desired order.
Greetings. I've got a nav-bar application that's misbehaving. I've got two buttons, one that shows all results from my database and another that shows a subset of my database. Of course, each button has its own action method. Both of these methods instantiate a view controller object of the same class.
If I start the app and only click the "all results" button, I do see all results. The goofy thing is that when I click the button for the subset of results (and see the subset of results), click Back on the nav bar, and then click the first button for the entire set, I see the subset again.
While debugging with break points all over the place, I noticed that the dealloc method of my results view controller doesn't get called. However, when I click Back and then click the all-results button, the alloc/init methods are indeed called again for my results view controller.
So even if I have a blatant memory leak, how is it possible that my freshly allocated/initialized view controller object has the same data as that of the previously instantiated view? Stepping through the code made this problem seem even more bizarre, as it appeared to be behaving properly...just yielding old data.
Any advice at all would be great. Thanks!
Calling "reloadTableData" on the table view should ensure the data is refreshed. Call that in the action methods.
Why do your buttons repeatedly instantiate the view controller? Why not have pointers to the view controllers as instance variables that you only have to set once and then can use at will?
This is just a wild guess, but it could be related to the reuse of tableViewCells. Try always creating a UITableViewCell, avoiding the reuse-identifier to see if the old data persists.
I figured out what was wrong a while ago and thought I would answer my own stupid question. :)
I had forgotten that I made my Database class a singleton and put a master pointer to "allResults" in the app delegate class.
Thanks anyway for your input. Every little bit helps me understand this new environment better.