Well, thanks Dave, Hunter, Richard and the rest.
I followed each of your suggestions, and I finally found the culprit.
A single binding, rather a nifty one, which I don’t know how to do better —
Maybe you can help. Removing this binding (alas losing functionality) window
opens instantly, regardless of the number of items.
First off — the issue is NOT in any of the table columns. They do have
complicated bindings, but all work fast and fine.
In the .xib there is also a custom view, only used as an accessory view to an
NSAlert dialog, when user choses to perform special editing on the items
displayed. (Kind of search-and-replace action).
In that view, there’s a popup button, populated by binding to a (quite special)
array controller. That array controller’s content-array has the binding that
breaks window loading.
I’ll try to explain:
This NSTable in the window displays a list of all “Measurement” entities
related to a specific “Sample” (the “representedObject” of the File’s owner).
For that I have a “Measurements Array Controller” in “Entity” mode, whose
content array is bound to File’s Owner’s “representedObject.measurements”
relation. All table columns are bound to that array controller.
Now each Measurement is connected via to-one relation to a “Species” entity.
In my custom view, I wish to populate a popup button with all the Species
entities which appear in the displayed Measurements.
For that, I created the “Used Species Array Controller” whose section in the
.xib appears below:
<arrayController mode="entity" entityName="Species" editable="NO"
automaticallyPreparesContent="YES" preservesSelection="NO"
selectsInsertedObjects="NO" avoidsEmptySelection="NO"
clearsFilterPredicateOnInsertion="NO" automaticallyRearrangesObjects="YES"
id="syR-1c-VXy" userLabel="Used Species Array Controller">
<connections>
BAD: <binding destination="4l9-1K-ojl" name="contentArray"
keyPath="arrangedObjects.@distinctUnionOfObjects.species" id="TQk-n5-RYc”/>
<binding destination="-2" name="managedObjectContext"
keyPath="representedObject.managedObjectContext" id="Vqg-dg-DdM"/>
<binding destination="xYM-bl-Wzq" name="sortDescriptors"
keyPath="sortDescriptors" id="3uW-GQ-bKN"/>
</connections>
</arrayController>
The “Bad” binding destination, is the Measurements Array Controller’s
“arrangedObjects”, and the model keyPath is “@distinctUnionOfObjects.species”
Effectively, when calculated, this “collects” all the species from all
displayed measurements, removing any duplicates. Nifty, isn’t it?
I can’t provide the list statically, in advance, because the user is free to
replace the species of displayed measurements - and although this is rather
“heavy” binding - I can’t see anything “recursive” about it, or otherwise
iteratively-dependent. I would guess this ArrayController should “Prepare” its
content array once - and forget about it, until time any of the Measurements
(arrangedObjects) mutate.
I know this isn’t easy to grasp… but any idea for how to improve this will be
greatly appreciated.
Thanks again!
Motti Shneor
---
Ceterum censeo Microsoftinem delendam esse
> On 4 Nov 2018, at 21:41, Dave Fernandes <dave.fernan...@utoronto.ca> wrote:
>
>
>
>> On Nov 4, 2018, at 2:24 PM, Motti Shneor <motti.shn...@me.com> wrote:
>>
>> Hi Dave and thanks for the reply.
>>
>> As you can see in the stack - there isn’t actually any “code” per-se that
>> runs at that time. Here is the actual method that fails:
>>
>
>> As for modifying the persistent store - I guess I don’t because the
>> database-document does not become “dirty”. If I double click one of the
>> “sample” entities that can be open - and the window is shown as expected,
>> then I close the document - there are no autosaves or changes recorded. The
>> modification time of the persistent store does not change.
>>
>> However - you’re right to point at
>> NSManagedObjectContextDidChangeNotification — how could I get it to pop?
>
> Set up an observer for that notification for your MOC and set a breakpoint in
> that observer.
>
>>
>> 3 of my NSTableColumn do have a formatter for the number presented - but why
>> should this affect the context, The columns are not “editable” in-place.
>
> Just trying to narrow this down without assuming too much.
>
>>
>> I will attempt to delete these columns and try again…
>>
>
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
