Re: Need a direction. App crash in CoreData while loading a window's nib
Re: Need a direction. App crash in CoreData while loading a window's nib
- Subject: Re: Need a direction. App crash in CoreData while loading a window's nib
- From: Sandor Szatmari <email@hidden>
- Date: Sun, 04 Nov 2018 18:04:16 -0500
If you can, can you establish the binding programmatically after launch? If
so, does the program crash once the bindings are re-established? … considering
if it is a launch issue or more systematic?
Sandor
> On Nov 4, 2018, at 17:25, Motti Shneor <email@hidden> wrote:
>
> 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="email@hiddenes" 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 <email@hidden> wrote:
>>
>>
>>
>>> On Nov 4, 2018, at 2:24 PM, Motti Shneor <email@hidden> 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 (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
_______________________________________________
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