Is it true that when the back button is taped, the current view is destroyed?
If so how can I prevent this?
I'm getting this idea because if I set an active item (item gotten by using Ext.getCmp) on the navigation view, tap on the back button and then set the active item again, the Ext.getCmp returns undefined.
Any ideas, solutions or workarounds for my problem?
Property autoDestroy is responsible for that. Note that it should be set for Navigator and affect on the children destroying, not to the Navigator itself. If it set to true - all poped items would be destroyed by back action, otherwise will be kept in memory
Cheers, Oleg
Related
The UINavigationItem is not deleting from the Navigator. It seems like it's locked on there and the viewcontroller.
How do I remove it?
You may have previously done embed-in NavigationController without noticing it. So go check that at menu editor.
Moreover, it's better that you unplug all associated navigation controller. So right click your item and see outlet to find if anything connected. If so, remove them all. After all this done, you should be able to remove the item properly.
Practically all of NSStatusItem has been deprecated for 10.10 and the behavior of the underlying NSStatusBarButton seems to be confusing.
Currently I am working on a menu bar application. When the user clicks the menu bar icon for the app, a method in my application delegate is called via target-action which displays an NSPopover (or closes it if it's already visible) with some information.
Normally, if you've associated, say, an NSMenu with an NSStatusItem when the user clicks on the menu bar icon that icon remains highlighted blue until the menu is closed. Similarly clicking the system volume icon pops down a slider and highlights its icon blue until the view containing the slider disappears.
However, since I'm the one opening the NSPopover, the system instead highlights the icon blue on mouse down, then returns it to normal on mouse up after my method has been called. Meaning there's nothing I can seem to do on that loop to maintain the highlight. I want the icon to continue being highlighted on mouse up and only return to normal when I tell it to (ie. when I close my popover.)
I have no idea how to do this. I've tried using
[self.statusItem.button setHighlighted: YES];
//or [self.statusItem.button highlight: YES];
when I receive the mouse up event in my app delegate and open the popover. The problem is the system still has it, apparently, highlighted this frame/loop from the earlier mouse down and immediately after I set it to highlighted, it sets it to unhighlighted due to the mouse up. I can get around this by encapsulating this in a method and running the method using a timer or delayed selector a split second later. This allows me to keep the icon highlighted but introduces a flicker; the icon is highlighted automatically as the mouse goes down, as the mouse goes up it unhighlights it for a frame, then my method re-highlights it.
I also figured perhaps I could use the deprecated setHighlightMode: and set it to NO to prevent the icon from being highlighted automatically on click, then using setHighlighted: / highlighted: to set it manually but that doesn't work either. Similarly, I thought maybe this would work as well:
NSButtonCell* cell = (NSButtonCell*)self.statusItem.button.cell;
cell.highlightsBy = NSNoCellMask;
But regardless clicking it automatically highlights the icon and dehighlights it on mouse up right after my method is called.
Basically:
The undesirable automatic highlighting behavior of NSStatusBarButton interferes with manually setting the highlight state, unless I delay manually setting it which introduces a short flicker.
The only thing that seems to successfully disable this automatic behavior is the deprecated setHighlightMode:, but this seems to prevent all highlighting, manual or not.
The only work around seems to be to add a subview to the NSButtonCell, add an event listener for mouse up and then set the highlight state of the superview as per here:
NSStatusBarButton keep highlighted
but I would think there'd be a simpler way to just... disable the automatic highlighting altogether.
tl;dr: Is there a way for me to easily obtain full control over when and when not my menu bar icon is highlighted, so that I can have it highlight naturally while my NSPopover is displayed?
I ended up solving this by not setting the NSStatusItem's action selector property. Instead I used NSEvent's addLocalMonitorForEventsMatchingMask:handler:. In the handler block I check if the event.locationInWindow is within my status item's .bounds. If so I send the message the .action would have manually and then return nil to prevent the event from being passed on. If it's not within the status icon's bounds I return event so it gets passed on normally. In my click handling method I use [self.statusItem.button highlight: YES/NO] when my popover is displayed/closed.
TL;DR:
In applicationDidFinishLaunching:
__block AppDelegate* appDelegate = self;
[NSEvent addLocalMonitorForEventsMatchingMask: NSEventMaskFromType(NSLeftMouseDown) handler:^NSEvent* (NSEvent* event){
if (NSPointInRect(event.locationInWindow, appDelegate.statusItem.button.bounds)){
[appDelegate clickedMenuBarIcon: event];
return nil;
}
return event;
}];
In clickedMenuBarIcon: I can then set the highlight state. Since I returned nil in my handler block it prevented the event from getting passed on so the automatic highlighting never occurs and I can do it manually.
If there's any bugs associated with this I'd appreciate any advice.
OK, here's the situation. I have:
A Webview
Lots of NSTextFields
Other unrelated controls
Normally, the Edit > Undo menu item links to First Responder's undo: action. And everything works fine + you can even "undo" while typing in an NSTextField.
Now, what if I want to handle this "undo" action, in a different way, only for my WebView.
I've been thinking of two approaches:
Link the "Undo" item to a custom action and check who is the First Responder. If it's the Webview, then do what needs to be done. Else, "pass" the event to the control. (However, when attempting a [FIRST_RESPONDER performSelector:#selector(undo:)], first it doesn't seem to recognize the selector and last but not least nothing happens.)
Link the "Undo" to the first responder's undo:(as usual), subclass the Webview and add a custom - (void)undo:(id)sender action. In that case though, when the webview is active, the "Undo" item is grayed-out, so I can't do anything whatsoever, not even check whether the custom method would be called.
Suggestions? How would you go about that?
What am I missing?
I think this is the answer: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/WebKit/Protocols/WebEditingDelegate_Protocol/
Also reference this: Removing undo actions for a WebView's NSUndoManager
I have a UIButton that trigger the IAP process. There is some time (2/3s or more if internet connection is bad) before an alert view is displayed (either asking for id and password, or the confirmation one). So one may click several times, thinking that the button is not working. And then you get as much alert view in a row as times you clicked and they are shown even if I quit the app and I'm on another meanwhile. That's pretty annoying.
My solution so far is to set a boolean as property of the UIviewcontroller. If it's false, click does nothing, else click trigger payment process. I set it to false on first click and in viewwillappear i get it back to true. The problem is that to be able to click the button again you must leave view and come back to it. That's not cool...
So here is what I'm looking for ideally : a function that is triggered as soon as any alert view of any kind is shown or dismissed. Show is better because i could use that to stop an eventual activity indicator I'd like to add too.
Thank you for you ideas.
Don't base it on the alert view being shown (you can't anyway). Instead, when the button is pressed, disable it or hide it (and show your activity indicator). When you start the purchase, add your controller as the delegate. Use the delegate methods to update the UI to enable / show the button (or remove it all together if more appropriate) when you get the callbacks which tell you the purchase is complete / failed.
Im looking for some help regarding to put a save like confirmation if some changes where made to a UITextField and UISegmentedControl.
Can I prevent the UINavigationController from pop the view? And then pop based on buttons in a AlertView?
I use the UITextField and UISegmented control to POST data to a webservice.
I perhaps need to use a modalView for this? but wanted first to see if someone have another idea, because I would like to keep navigation clicks down if possible.
Any suggestions for this?
Thanks,
Why not just using a UIAlertView?
EDIT: On second thought, and re-reading your question + comment, I would recommend to use a Modal View with classics OK/Cancel buttons + a UIAlertView(s) for confirmation(s). (UIAlertView "poping" on OK/Cancel is easy to do via UIAlertViewDelegate)
That's what Modal views are for, block UI until some user action has been completed. Like a form. This is how I do all my forms, and how Apple does (just look at the create mail screen for an example, or any form of iOS apps)
Adding a "Magical" action requiring user interaction on the back button of a navigation controller is bad in terms of user experience, if you hit back, you expect the view to pop, nothing else. I would then be surprised if Apple SDK even allows to cancel that event...
You can do what you would like without the need of a modal view.
First, you can use your text field's UITextFieldDelegate to set a flag in your controller when the field content is modified. You can reset this flag when the data is sent out.
Then you could override your UIViewContorller's viewWillDisappear to show an alert to the user in case new data have not been posted at the moment the view is going to disappear and give him the possibility of sending it to the server. This method will be called when you move to a different controller in your navigation UI, and you will not have a chance to "reject" the operation.