Hello Ken If you don't have a handle on the basics, it's foolhardy to get into > advanced techniques.
I am trying to understand these techniques step by step, it is really difficult for me when everything is hidden :( > > > I assume i should call a one run through the runloop manually, but how? > I recommend that you not attempt to "invert" the event loop or build one > yourself. The "modal session" methods of NSApplication > (-beginModalSessionForWindow:, -runModalSession:, and -endModalSession:) > seem like a good fit for your requirements. It does entail implementing > your long operation as a bunch of short work units. > Could you please explain what will happen when i call these methods? Why is it better than just calling "update label text and go through the runloop"? Why is it "the right way" and why does it trigger running through the run loop? I would never guess i need to call it - reading apple docs it would only lead me to use it only to display a modal window (the one, that makes the runloop "receive" only those events that are sent to that window and switches the runloop into another mode with another set of sources). > > > > Here's what CoreFoundation reference suggest to do: > > > > CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0, false) > > > > this is supposed to call only one run through the runloop. But, according > to > > the documentation "If multiple sources or timers are ready to fire > > immediately, only one (possibly two if one is a version 0 source) will be > > fired, regardless of the value of returnAfterSourceHandled.". I have more > > than one source: it is a label update (well, GUI events, i am not sure > how > > to call it - something like redraw i guess), event tap source (that is > > installed into another app), and i am also observing another > application's > > state changes (when it becomes active/showed/hidden/inactive). Therefore > i > > can't specify 0 is the second parameter? Then what number should i > specify? > > 0.1? 0.5? 1? 10? how can i know how long it needs to be executed? And i > dont > > still want to slow down the processing waiting 1 second on every label > > update. (i call these updates several times during processing the "big > > file") > > All of these questions indicate that 1) you're deep in the weeds and over > your head, and 2) you're caring about irrelevant minutiae of implementation > details, exactly what you should avoid paying any attention to. > Perhaps, but let me explain a little more what my task is: It can be a really huge file to process (it may take 1,5,10,20, 30 minutes to process). Therefore, after every lets say 1 second i want to display the progress (i want to look it smooth, not to give the feeling of freezing of the app - thus 1 sec - it's like copying a file, but involving a lot of Applescripting). Waiting for another one second would result in twice than needed processing time (40-60 minutes). Is it the "price of [indication of] a progress"? And i really have no understanding in what do these methods do, why there is this "time idea" and how is it supposed to be used (how a developer can have any idea of what time does it take to process a set of events while preemtive scheduling is enabled? I try to notice similarities with window's timeout idea, but in windows that thing was created for long input output operations, to make application "more responsive" - for example, after 10 secs passed, windows will ask a user that the app is not responding and if he or she wants to wait more, or to kill the task. Sorry for windows analogy, but that's what i've been working with for a long time before). You didn't answer on that question, i guess because you didnt want to repeat some reference, but which one then? > > > o Why isn't label updated immediately on OS X 10.5, when i call > > -setTextWithMnemonics? Does it require passing the event loop to update? > > First, you're going to have to explain what -setTextWithMnemonics: is. I > don't find any method by that name in Apple's docs. > I am sorry, it was -setTitleWithMnemonic method of NSTextField, i wrote that by memory > Typically, when you set a control's value, it merely marks itself as > needing display. It does not display immediately. Then, the framework > takes care of displaying all views and windows needing display at an > appropriate time (where the framework defines what's appropriate). > But when is it appropriate then? The only option left for me is multithreading? But then this AppleScript "slowdown" appear. > > More questions you shouldn't care about. -[NSApplication run] is built on > NSRunLoop, which is built on CFRunLoop. Beyond that, you are not entitled > to know. If you did know, you'd rely on it, which would constrain Apple's > future flexibility in changing the frameworks. > Of course, but if i don't care, i won't be able to implement what i want and to make it work right and fast at least on two systems - Leopard and Snow Leopard :( Apple can easily change things, of course, but it is impossible to create an application that works everywhere as time passes. Things that make me think so are examples, like Carbon is deprecated - all its documentation is vanished from Apple website, so, i believe, will happen to framework itself either. What will happen to all the applications that had to be supported? They are supposed to be rewritten or die. It's alright, as long as the developers are aware of that. Same happened to AppleScript Studio - we must use AppleScriptObjC instead (the latter doesn't even launch on Leopard, while the former is supposed not to be able to work on next versions of MacOS). My customer wants the application to work on Leopard (perhaps he's just got a slow mac or something - it's not up to me to convince him to update it to Snow version), while most of the users have Snow Leopard. Also i used some tricks that are not explicitly described in references to make my application work (these tricks luckily for me work on both Leopard and Snow Leopard), because my application is not supposed to operate like an ordinary one, but, rather, like an additional plugin to another application. It shouldn't be active all the time, allowing that another "master app" to be active. It receives the keyboard events that happened into master app, by installing Event Taps there. If my application becomes active, it sends all the keyboard events occured to the master application. Well, maybe it is not that sophisticated, but i have a strong feeling it won't work "tomorrow", or if i am lucky, the day after tomorrow, but so are a lot of things in the world of Apple :) as i observe. So why can't get an understanding of how the things work under the hood at least for today? Thanks, George _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
