I have multiple custom NSViews in my Cocoa program. I am looking for a way to force them to invalidate without having to add additional code while the program is running. If I were doing this with on Windows with the .NET framework, I would just drag part of my program offscreen and drag back on again. Areas that was offscreen get invalidated when they come back on screen. I haven't figure out how to do this with Cocoa - OSX.
The methods setNeedsDisplay should do it:
- (void)setNeedsDisplay:(BOOL)flag
- (void)setNeedsDisplayInRect:(NSRect)invalidRect
Docs here
Windows on Mac OS X are buffered by the Window Server and can't be forced to redraw by moving them around the screen. The only way the user can force a redraw is to resize the window.
Why do you need to do this, though?
Minimize the window and unminimize it. That happens to force a redraw.
I recommend you try F-script http://www.fscript.org/. It allows you to call methods on Cocoa objects while your program is running.
You could use it to call the setNeedsDisplay:(BOOL)flag or setNeedsDisplayInRect:(NSRect)invalidRect methods directly on the view you would like to invalidate.
Related
I'm not sure what causes it, but I and others on my team have found that, for some reason, iOS sometimes decides to completely disable all animations within our app. iOS general animations (parallax, app switching, home button, etc.) are still enabled, so it's restricted to our app.
This wouldn't be so much of an issue if it weren't for the fact that it seems that some things like -[UIResponder becomeFirstResponder] don't work immediately after what would otherwise be an apparition animation (for instance, in a viewDidAppear method, or the block of a -[UIViewController dismissViewControllerAnimated:completion:]).
I've checked our code to ensure this isn't something we do, and indeed we simply pass YESs into the Cocoa Touch framework when it asks if we want things animated, and at no point in our code (or, as far as I know, in our 3rd-party SDKs) is +[UIView setAnimationsEnabled:] ever called. Likewise, I didn't do anything in iOS settings like "Reduce Motion", and simply restarting our app or letting the iOS device sleep will reverse this state.
So, what might cause iOS to disable our app's ability to use system animations? Additionally, Does this affect how/when/if delegate methods and callback blocks are being called?
Also, is there a way to detect, trigger, or reverse iOS's decision to disable animations?
Restarting app development after a 15 year hiatus. Current project is conversion of old windows-type command line utility into interactive OS X windowed app.
I created a view delegate inside main window and can draw and update NSTable view.
The updates are generated in the App's main loop which takes a UDP/TCP stream, parses and updates view via appropriate delegation.
Here's the problem: When I run the app, the main window does not apparently get
focus (window control buttons on upper left are grey), the Menu created from my .xib is inert, and the window itself does not respond to resizing or to mouse hits inside the table view scroll bars. Also, the mouse pointer is the spinning beachball when over the App's window.
My guess is that I am not providing time to the Objective C run loop for event processing. I do send a "display" to my window on every iteration of my app loop, but I guess it is not sufficient (Apple is not very clear about what objects get what messages when sending this kind of update message). Am I on the right track?
Is there a way to let the system Event loop run an iteration each time through my app main loop?
Thanks!
Update: I tried explicitly providing event loop time in my app's main loop with:
[[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:0.1]];
There was no apparent change in app behavior.
My guess is that I am not providing time to the Objective C run loop for event processing.
In this case, I recommend you read about Grand Central Dispatch, which provides concurrency, allowing the GUI to remain responsive.
There's a good explanation of GCD here and whilst it looks like a large and complicated subject, you'll probably only need a few lines of code to make use of GCD. For example: -
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
// do some work
});
Despite comparing the nibs and connections between my code and a freshly created .xib prototype, i could find no reason for my code to not get focus.
The fix was to move my code guts into the project with a new .xib.
This works but is unsatisfying
Is this really the proper and only way to programmatically set the target of an animation in a Windows Store app?
Storyboard.SetTarget(animation, someElement);
Storyboard.SetTargetProperty(animation, "Width");
It just seems odd not to use an instance method or property on either a Timeline or Storyboard.
It's the programming equivalent of reaching in your car window and using the interior handle to open the door.
Luke
It is the correct way, yes. I do agree it could be made simpler, but it is how it has been since WPF.
Does anyone have any insights into when/under what conditions applicationWillTerminate is called in iOS 5/6?
I've got some logic i'd like to execute whenever the application terminates (not moves to the background), for example if the user navigates to the application bar at the bottom of the screen by double tapping the home button and force quits the app.
when i try to do this on a test device, applicationWillTerminate does not seem to get called. Is there a reason for this?
My plan B is to tie that logic to some persistent object like a singleton or a static that is automatically destroyed when the app quits.
Any suggestions?
thanks
Have you read the documentation for applicationWillTerminate:,
It says,
For applications that do not support background execution or are linked against iOS 3.x or earlier, this method is always called when the user quits the application. For applications that support background execution, this method is generally not called when the user quits the application because the application simply moves to the background in that case. However, this method may be called in situations where the application is running in the background (not suspended) and the system needs to terminate it for some reason.
There is a "maybe" mentioned there. Probably that answers your question. So it is not necessary that this will get called when you quit the app. Probably you might have to use UIApplicationExitsOnSuspend to disable multitasking and then it might get called while putting in background. But that again depends on your app requirement. If you cannot disable multitasking, you might have consider doing that in applicationDidEnterBackground method or so. I am not sure if there are any other delegate methods which will help in identifying the force quit.
Is there a quick and easy way to have the app go back to the same screen after I put it in background mode?
I know there are frameworks just for this stuff, but has anyone done it without much sweat?
Thanks
In your app delegate, add a line to the applicationDidenterBackground: method that stores the current page via NSUserDefaults.
Then in the applicationWillEnterForeground: method, load up that saved value and restore the page.
Multitasking should enable this, while a device has enough memory to keep your app open. Otherwise how about using NSUserDefaults to store a string reference to your view?
As of iOS 5.1, there is no quick and easy way.