I have to do a bit of processing before my app can start printing, so I do that on a thread, and once it is all done, I do
dispatch_async(dispatch_get_main_queue(),^(){
ULIPrintableView *viewForPrinting = [[ULIPrintableView alloc] initWithData:data];
NSPrintOperation *operation = [NSPrintOperation printOperationWithView:viewForPrinting];
NSPrintPanel *panel = operation.printPanel;
ULIPrintAccessoryViewController *settingsVC = [ULIPrintAccessoryViewController new];
viewForPrinting.printOperation = operation;
settingsVC.printView = viewForPrinting;
[panel addAccessoryController:settingsVC];
[operation runOperation];
});
All works fine, except that for an NSScrollView (wrapping an NSTableView) in the accessory view.
That view scrolls perfectly with a regular wired PC mouse attached to the Mac, but with an Apple trackpad (both MacBook or the external one) and two-finger scrolling, the scroll view does not update until you remove your fingers from the trackpad.
It seems as if some sort of touch-moved events were not being delivered.
If I change the last line in the block from -runOperation to -runOperationModalForWindow:delegate:didRunSelector:contextInfo: scrolling is OK again, but I don't really have a window I could show this sheet on in my use case.
If I call either runOperation method directly instead of doing my threading the scroll view scrolls fine.
So I have a workaround and a suspicion:
If I use -performSelectorOnMainThread:withObject: instead of dispatch_async(), the scroll view works.
I suspect that -performSelectorOnMainThread:withObject: doesn't use dispatch_async() under the hood, but that delivery of touch-moved events for wheel scrolling does. So when I -runOperation, I block the main dispatch queue and those events pile up "behind" my modal run loop.
Not too happy with this workaround though. What guarantees that -performSelectorOnMainThread:withObject: won't some day block the main queue as well?
Related
The problem: Attempting to display a window with text from applicationWillFinishLaunching will NOT draw itself if other processor-intensive non-UI code is immediately called.
Background: I have a helper app that when launched may or may not interact with the end user. While it is "deciding" if it needs to put up a window to ask user questions, there may be anywhere from 1 second to 10 seconds that elapse (after launch it's off in non-UI capable library code communicating over the internet).
So I wanted to be kind to the user and put up a "mini-alert"* window with "working, please wait...", prior to heading into that library code, which I will dismiss once that processing has elapsed.
It seems as if the app itself doesn't have time after launch to even draw this mini-alert (it's just an NSWindow, with an NSView, some text, and no buttons).
If after the library code returns and want to put up either an error alert or a query window for the user -- then at that point the mini-alert draws as expected. However, if I close the mini-alert (see below) and then put up an NSAlert -- the mini-alert doesn't have enough time to dismiss itself.
- (void)applicationWillFinishLaunching:(NSNotification *)notification
{
[NSApp activateIgnoringOtherApps:YES];
briefAlertWindowController = [[NSWindowController alloc] initWithWindowNibName:#"BriefAlertWindow"];
[[briefAlertWindowController window] center];
[briefAlertWindowController showWindow:self ];
[[briefAlertWindowController window] orderFront:self ];
[[briefAlertWindowController window] display];
[[briefAlertWindowController window] makeKeyAndOrderFront:nil];
}
and dismissing the mini-alert:
- (void)dismissMiniAlert
{
NSWindow * theWindow = [briefAlertWindowController window];
[theWindow orderOut:nil];
}
NOTE that neither NSWindow not NSWindowController have been derived/subclassed for this mini-alert.
I'm using the term "mini-alert", because I've noticed people get annoyed about the concept of a "splash screen". While the functionality IS similar -- I'm really just trying to let the user know that an unavoidably long operation is taking place.
It sounds like a threading problem. The splash window can't draw itself on the main thread because the main thread is busy doing the processor-intensive operation. Properly, your processor-intensive stuff should all be happening on a background thread. If you can't do that, you need at least to get off the main thread long enough to give the runloop a chance to draw your window. Just introduce a delay.
When I try launching my app through Spotlight without building it through XCode, the NSWindowController displays the unmodified nib (with the standard gray background color, etc) for a split second before windowDidLoad finishes. This looks awful, since views are in the wrong places and aren't colored correctly.
I tried removing everything from windowDidLoad to see if something in there was slowing it down, but that didn't improve things. I also tried moving the setting of the background color to initWithWindowNibName, but that didn't help either.
Is there a way to delay showing the window while it finishes loading?
Here's the code I'm using to initialize the NSWindowController:
self.windowController = [[WindowController alloc] initWithWindowNibName:#"WindowController"];
[self.windowController showWindow:self];
[[self.windowController window] makeKeyAndOrderFront:nil];
Disable NSWindowController's "visible at launch" property in Interface Builder.
(Of course, I post the question then immediately figure out the answer.)
I have a VC that has an inputAccessoryView that is used to display a textfield (much like the messages app). When I push this view onto the navigation stack everything works fine and by that I mean that the tableview adjusts its insets to make sure nothing scrolls underneath that accessory view. However, if from that view I push on another instance of the same view controller class the insets will not be adjusted and the scrolling of the table will be behind the accessory view.
This issue is seen in iOS 8 only. The other interesting thing about this is that if you then click in the accessory view to open the keyboard the insets are adjusted properly for the keyboard being visible and again when it's hidden.
Also if you don't click the text field to fix the issue and hit back the previous VC is broken as well.
I'm fairly certain based on the information above that this is an iOS 8 bug. I'm hoping someone has seen this and come up with semi reasonable fix.
Nasty solution but a solution nonetheless:
- (void)viewDidAppear:(BOOL)animated
{
[super viewDidAppear:animated];
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.01 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[self.inputAccessoryView.inputAccessoryTextField becomeFirstResponder];
[self.inputAccessoryView.inputAccessoryTextField resignFirstResponder];
});
}
This allows the view to redraw the insets
A NSStatusItem has a NSMenu attached, and one of the buttons of the NSMenu opens a NSWindow. Whenever one of these buttons is clicked, the window opens as expected and works properly, but another display of the NSStatusItem is opened.
The NSStatusItem is a clock, so I can see that it is updating correctly. However, the cloned NSStatusItem doesn't have its own menu. If I push the button that makes the window more times, more cloned versions of the NSStatusItem pop up.
Everything works fine except for this.
That's not a whole lot of information to go off of, but there's nothing else I can think of that could potentially help you. I would be happy to provide more information or try something.
EDIT: Every time the button is clicked, awakeFromNib is somehow called, which is why another half-working NSStatusItem happens.
EDIT: Temporary workaround is to put the awakeFromNib method in a dispatch_once.
EDIT: Added method that is triggered when button is clicked, as suggested by #zpasternack
- (IBAction)preferences:(id)sender {
self.windowController = [[NSWindowController alloc] initWithWindowNibName:#"PreferencesWindow"];
[[self windowController] showWindow:self];
}
Is the NSStatusItem contained in the PreferencesWindow nib? That might explain it, since you're loading the nib each time the button is clicked.
Also, is there a reason you need to recreate that window each time the button is clicked? Maybe you could only do it the first time?
- (IBAction)preferences:(id)sender {
if( self.windowController == nil ) {
self.windowController = [[NSWindowController alloc] initWithWindowNibName:#"PreferencesWindow"];
}
[[self windowController] showWindow:self];
}
I'm using a view-based NSTableView with a custom NSTableRowView. I would like to use custom row background drawing via drawBackgroundInRect, based upon mouse location using trackingAreas. The goal is to draw a custom background for the unselected row the mouse is currently hovering over.
This is virtually identical to the HoverTableView example from the WWDC 2011 session View Based NSTableView Basic to Advanced. You can see that behavior in action in the Mail, Contacts & Calendars System Preferences Pane in the account types table view on the right.
Unlike the examples, I have thousands of rows in my table view. Everything works as in the examples unless I scroll the table view rapidly (e.g., with a two-finger flick via trackpad). In this case, it seems that updateTrackingAreas is not called fast enough. Rows that scroll under the mouse get highlighted but are never notified that the mouse left their tracking area and therefore remain highlighted. The result is mulitple rows showing the mouse-over highlight and, due to the reuse queue, these will scroll off one end of the table view and reappear on the other (with different data of course) still highlighted as if they are moused-over. Scrolling slowly eliminates the problem; but considering I expect to scroll thousands and thousands of rows, scrolling slowly is not an expected user behavior.
I've tried various combinations of NSTrackingAreaOptions to no avail and am now stumped. Any suggestions on to solve this issue would be appreciated.
I think the answer to the question is "you cannot," i.e., that updateTrackingAreas for NSTableRowView in a fast-scrolling NSTableView does not happen consistently fast enough on the run loop to rely upon it for determining if the pointer is inside a row view or not. Again, see the HoverTableView example code to see where updateTrackingAreas is being used.
I do think I have a suitable solution though. I noticed that Twitter for Mac (RIP) has mouse-over views that appear with mouse movement but disappear on scroll, very similar to the mouse-over highglight I was hoping to achieve.
To execute this, I basically made my custom NSTableRowView have a delegate (my custom NSTableViewController) whom it would ask if it should highlight on hover. I used a custom NSScrollView for my NSTableView and called
[self.contentView setPostsBoundsChangedNotifications:YES];
in its awakeFromNib and also made it register self as the observer of that notification. On receiving that notification, which implies that my table view is scrolling, my custom NSScrollView forwards a message to my NSTableViewController.
When my NSTableViewController receives the message that the table view is scrolling, it disables highlighting on mouse-over and, if there is not already a valid timer running from a previous notification, fires a short timer to reenable highlight on mouse-over once scrolling has stopped. As an extra precaution, at state transitions between enable and disable highlight on mouse-over, my NSTableViewController uses enumerateAvailableRowViewsUsingBlock to clear mouseInside for every row view.
Not sure if this is necessarily the best way, but it achieves the effect I wanted.
The solution for this issue is described here: mouseExited isn't called when mouse leaves trackingArea while scrolling
My updateTrackingAreas method now looks like:
- (void)updateTrackingAreas {
if (trackingArea)
[self removeTrackingArea:trackingArea];
[trackingArea release];
trackingArea = [[NSTrackingArea alloc] initWithRect:NSZeroRect
options:NSTrackingInVisibleRect |
NSTrackingActiveAlways |
NSTrackingMouseEnteredAndExited
owner:self
userInfo:nil];
[self addTrackingArea:trackingArea];
NSPoint mouseLocation = [[self window] mouseLocationOutsideOfEventStream];
mouseLocation = [self convertPoint: mouseLocation fromView: nil];
if (NSPointInRect(mouseLocation, [self bounds]))
[self mouseEntered:nil];
else
[self mouseExited:nil];
[super updateTrackingAreas];
}