So, for my project I needed to have some custom windows, which I created by subclassing NSWindow.
Those also have their own Titlebar Views that display some controls, of of them being the regular close button, hooked up like this:
[closeButton setTarget:[self window]];
[closeButton setAction:#selector(close)];
Now this works all perfectly fine, except for windows in which I have a WebView. Whenever I load up any Website in the given WebView, the close Button doesn't do anything anymore (before it works fine as well)
I have absolutely no idea, why this is happening, any kind of pointers would help a lot
Could the webview be replacing the target/action, or providing a delegate method that denies the close action?
Why don't you set some breakpoints to check the target/action or insert some tracing to print out what they are set to when the web windows are open?
Related
I have an application that needs to display a window on top of anythings else. To achieve this I call [window setLevel:NSStatusWindowLevel] on my main window.
This works fine except that I can't use any modal dialogs or alerts from this window. The problem seems to be that [NSWindow beginSheet...] internally calls setLevel: on the target modal window with a value lower than NSStatusWindowLevel, so the modal dialog is displayed behind its parent window. The same happens when using an NSAlert from a window with higher window level, the alert is displayed behind.
The only [ugly] workaround I found is to inherit NSWindow, override setLevel: and prevent setting a lower level value on these modal windows but this only works when I have control over the window and doesn't work for NSAlerts.
Is there a more elegant solution for displaying modal dialogs from a NSWindow with high window level value that will also work with NSAlerts? Or I will be unable to use NSAlert with this approach?
one thing that comes to mind is to check if NSAlert uses a special NSWindow subclass you could make a category on it and hook the setLevel: method via swizzling (here is an example of extending an existing method via swizzling). there is nothing stopping you from doing this in a plain NSWindow subclass either.
I know its not the "elegant solution" you'd hoped for, but its the only one I know off the top of my head. I suppose it is slightly more elegant in that you don't have to insert your custom subclass everywhere throughout your program, but less elegant in that you are messing with the objective-c runtime using code that simply seems wrong.
I am trying to tidy up my UI by consolidating various things in a Tool Bar, and am utterly confused. I am using Interface Builder rather than constructing the controls programmatically, because my UI is fairly simple and not particularly dynamic.
What I did did so far:
Added an empty tool bar.
Dragged two previously existing and working buttons onto the tool bar. They changed their class from UIButton
to UIBarButtonItem, and the inspector now shows them as having no
Sent Actions or Referencing Outlet, but the the previous action &
outlet in the View Controller - responding to taps, setting the
label of the button - still work.
Created a new Button directly
in the tool bar. Wired up its action & outlet by ctrl-drag in the
normal way. The inspector shows the Action and Outlet for this
button as connected, which is nice, but sadly neither of them works.
Clicking the button does not invoke the action; setting the label of
the button does not cause anything to happen on the screen, even
after I tried prodding the tool bar with a setNeedsDisplay.
I'm not sure what to try next. Googling has shown me that I'm not the only person to find using UIToolBar via Interface Bulder difficult and confusing, but I haven't found a solution to my exact problem.
I don't particularly want to resort to creating my entire GUI programmatically just to tidy up a few buttons. Creating all the controls in Interface Builder outside the tool bar, getting them wired up and working, then moving them into the tool bar would presumably also work - but it would be a kludge, and would leave me still none the wiser if anything went wrong later.
Should you try using UIBarButtonItem instead of UIButton? It works for me.
i had a similar issue.
Did you created an extra UITapGestureRecognizer for root view ?
Maybe for something like > When elsewhere than UITextView clicked, resignFirstResponder for all UITextViews !
In my case, on 7.1, that extra UITapGestureRecognizer prevented transfer of event to IBAction of UIBarButtonItem which is inside an UIToolBar.
IBAction was made on Storyboard by Ctrl+Drag.
on 8.1 it was working. Not on 7.1
Read some suggestions to create an extra UIView and putting all visual elements into that extra UIView except UIToolBar
My iOS app sometimes displays a Greystripe fullscreen ad on startup. If this ad shows, then when I dismiss it, later I will tap a textfield in a UIWebView but the keyboard won't show up. However, if the Greystripe ad DOESN'T appear, then all is well and the keyboard will show up as expected.
After doing some research I think it has something to do with Greystripe making itself the first responder, but I'm not sure how to fix this.
Edit:
I use adwhirl and so to get the startup ad I do exactly as it says here: http://wiki.greystripe.com/index.php/AdWhirl
The UIWebView is inside another controller that is presented with presentModalViewController:animated: from the main view.
I narrowed the problem down: the problem is caused after initiating Greystripe, which occurs either from the full screen startup ad that I initiate manually or from AdWhirl automatically initiating it to display a 320x50 Greystripe banner.
After hours of debugging I finally figured it out. I use SVProgressHUD to show loading status while my UIWebView is loading. SVProgressHUD.m makes itself the key window, then when it is dismissed, it returns the key window status to the "topmost" window. For some reason Greystripe, unlike all the other ad networks I'm using, makes itself the topmost window. So the problem could be Greystripe making itself too important, or SVProgressHUD miscalculating the topmost window!
To solve this, I had to manually make my view controller which contains my UIWebView the key window every time after dismissing SVProgressHUD:
[SVProgressHUD dismiss];
[self.view.window makeKeyWindow];
I was wondering how to remove the proxy icon in the bar of my mac app. I've added an image so you can see what Icon I'm talking about
Thank you in advance!
The icon is included in the titlebar of the application automatically when you've created an NSDocument based application.
You can remove the proxy icon by returning nil from the -[NSWindow representedURL] method. This could be accomplished by using a custom NSWindow subclass with the method overridden; or simply setting the property to nil at the appropriate times.
Be aware, you might loose other functionality you normally get for free by changing this behavior, such as the dirty/clean indicator for the window, or some prompting to save when closing the window.
Alternatively, if you wanted a different image, you could use:
[[NSWindow standardWindowButton:NSWindowDocumentIconButton] setImage:customImage]
Then implement -[id<NSWindowDelegate> window:shouldPopUpDocumentPathMenu:] to return NO to prevent the popup menu from appearing.
If your application isn't actually document based, or the window doesn't represent a document, consider refactoring to present this window a different way, rather than being a document window.
There is some additional information in the Cocoa window documentation.
I would like to hide a window before the app has loaded. Now I know to hide a window you can use this;
[window2 orderOut:nil];
which works fine when you click on a button but what if I wont it to be hidden before or whilst the application has loaded?
So sorta need an IBAction on when the application loads
In Interface Builder, you can uncheck the box (in the window's attributes pane) that says to show the window at startup.
Or you can put that line of code in your app delegate's applicationWillFinishLaunching (or perhaps applicationDidFinishLaunching) method. (Might not work in the first one, I'm not sure.)
But I'd go with the first option, personally.