Re: bindings via file's owner don't update
Re: bindings via file's owner don't update
- Subject: Re: bindings via file's owner don't update
- From: Mikkel Eide Eriksen <email@hidden>
- Date: Thu, 2 Dec 2010 17:54:25 +0100
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden