On Dec 2, 2010, at 1:47 AM, Quincey Morris wrote: > On Dec 1, 2010, at 11:08, Mikkel Eide Eriksen wrote: > >> See line 48 & onwards below: >> >> http://code.google.com/p/cocoa-gedcom/source/browse/trunk/GCCoreData/src/GCDocument.m >> >> (there are probably lots of terribly ugly non-Cocoa things in here, I'm only >> just starting out and come from a mostly perl/python/java background) > > Well, this would have be a much shorter thread if you'd posted a link to the > code earlier. :)
That part wasn't committed then ;) > Your issue is absolutely nothing to do with bindings, but rather a > misunderstanding about how window content gets updated (drawn). In general, > things you do in code that require the window to be redrawn are deferred and > coalesced, and the drawing occurs in a separate iteration of the main event > loop. > > In your 'readFromURL...' method, you do things that require a redraw (change > properties that UI views are bound to), but you're in a tight compute loop > till the entire process is complete. You never return to the main event loop > until the end, so the window never updates. > > That's why invoking 'display' on the window seems to "fix" the problem, but > that's not the correct solution because it shuts out the entire deferred > drawing mechanism that's fundamental to Cocoa. > > If opening a document is a long process (more than a couple of seconds), then > there are three basic approaches: > > 1. Break the operation into smaller steps, and arrange to return to the main > event loop after each step. (This means you're going to start the process in > 'readFromURL...', but you're going to return more or less immediately and > finish the process elsewhere.) > > 2. Move the guts of the process into a background thread, so that user > interaction (including window updates) . > > 3. Process events during your 'readFromURL...' loop. (This is called a modal > event loop.) > > All three approaches are non-trivial, though not exactly rocket science once > you're familiar enough with the frameworks. However, the progress window is a > considerable complication, and the best implementation depends on which > approach you choose. > > Approach #1 is probably the easiest of these. You can use 'performSelector: > ... afterDelay: ...' to "schedule" a separate method that performs a few > iterations of your loop. Or, you can look into GCD and Blocks. > > Distasteful as it may be, your best approach *for now* might be: > > 4. Don't use a progress (loading) window at all, but just let opening a > document take as long as it takes. Come back to this refinement of the UI > later, when Cocoa is more familiar. > > I must also issue the standard warning: If this is basically your first Cocoa > project and you're using Core Data, you're in for quite a lot of pain before > you're done. I've done some smallish Cocoa-projects for myself, but this is my first "real" one. You gotta learn somehow, right? I'm familiar with some of the ideas behind Core Data, since I work with WebObjects (albeit I mostly interface with the model, I don't do much development in the model itself). Many thanks for the thorough reply. I think I'll postpone the Loading window and concentrate on the model and (actual) interface for now. I mostly added it since loading a large file (ca 3500 individuals) takes several seconds and I wanted some feedback on the progress. Maybe once I've gotten a little deeper with the model and mapped most of the tags, I'll take a closer look at instruments and see if there are some obvious bottlenecks. Regards, Mikkel
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
