I don't have code here, but under cocoa it should be:
[[NSRunLoop mainLoop] runUntilDate:[NSDate distantPast]];
currentLoop may be needed in some cases (I believe in case runModal is used).
I don't think Mac app repaints the window; rather,
1. There is per-window bitmap of window contents used by compositor
2. Core Animation is run in different thread, so animations of layer backed views may run, but events still won't be processed.
Overall, I would not use the above hack unless absolutely necessary. -[NSObject performSelectorInBackground:withObject:] works well for me in a few iOS apps, and combined with -[NSObject performSelectorOnMainThread:withObject:] and (if you can use ObjC2.0) @synchronized, it should be quite easy to retrofit existing apps to be multithreaded.
And if you don't want to mess with threading (although you probably should) also consider scheduling tasks to be run in a timer but "as soon as possible". So when web service gets a request, build a list of tasks to perform, and schedule parsing of the task with a timer that runs "right now" (but, in effect, after event parsing runs next). After task runs, remove it and schedule next task to be popped from the queue and parsed in the right-now-timer.
But... Anything except threading is bound to result in poor UX with regard to interactivity unless you take a LOT of care that each task is very, very short. So all is well if you just want to repaint stuff... Not so much if you want to add a cancel button!
> I have an application which is not multi-threaded (it runs ona single webservice connection, thus the actions are blocked anyway to one after the other). It runs tasks which run in clas methods and which interact with disks and networks. Until now, I was logging all meaningful stuff with NSLog() and I could see progress while the application was running, pretty primitive.
> I now started to write output on the screen. Right now it is a Logger whcih has a console with a TextView and I print out everything there, scrolling the textview continuously to the last message. In the future, I might also write directly text in dialog boxes and similar things in the future. An action is thus typically cyclical:
> while (stuff to do)
> fetch a chunk;
> log information;
> process chunk;
> log information
> The problem? There is no GUI update until everything is done.
> I could make the application multi-threaded: having only one, controlled, worker-thread that calls the main app just to update the window. This probably works but has a certain effort.
> Is there a way to tell the GUI to do some of its stuff? Some way to relinquish control ? It would be a coarse way of course, but before running another loop sequence I can just tell the main runloop to its update stuff?
> Should I mess with the current NSRunLoop and tell it to run? Or a similar trick?
> This would perhaps also allow to intercept the pressure for a "Cancel" button. Currently I have none, but I might need one in the future.
> Incidentally; I have seen that GNUstep apps are even more sensible than Mac apps regarding this: The Mac app with the same code still redraws its windows, the GNUstep application not.
> Gnustep-dev mailing list
> Gnustep-dev@... > https://lists.gnu.org/mailman/listinfo/gnustep-dev