According to documentation for NSArrayController, the instance method didChangeArrangementCriteria (no argument) “is invoked by the controller itself when any criteria for arranging objects change”.
So I thought that if I implement that in MyDocument as didChangeArrangementCriteria(), it would be called when I click a column header (making it sort on that column) or do a search (filterPredicate). But the handler is never called.
What am I missing?
Hi,
as you wrote, didChangeArrangementCriteria is an instance method of class NSArrayController, it’s not a delegate method nor a notification. You can use it only if you subclass NSArrayController and override the method
The issue is now old hat, Stefan, but I forgot to thank you for setting me straight about this – despite it’s clear from the documentation, I missed what should have been the obvious to me. Thanks!
Subclassing the array controller was easy, but the rest was extremely gnarly:
For subclassing, I just set the class of the array controller in IB to the new script file ArrayController whose parent is NSArrayController, and which has the didChangeArrangementCriteria handler, which includes a continue statement + my extra code. And a couple of properties to outlets.
The whole reason for this, however, was my quest for undo/redo of the table, which was the really gnarly thing – actually VERY gnarly!
To make arbitrary long sequences of undo/redo work, I needed to record everything that may affect the content and order of rows and columns. I finally think I’ve got it all working though. Part of the added difficulty was that I have a popup-button in the table, AND strict validation on which combinations of some values in different cells are valid, trying to automatically disable disallowed combinations – AND undo/redo of that which also must preserve validity, AND a bunch of rows can be modified in bulk from the toolbar, AND I need to keep the table sorted… puh!
I have now done a fair bit of testing, also on large tables (thousands of rows to ensure the extra coding didn’t slow things down too much). The downside of the undo/redo capability (besides it took a couple of weeks to do) is that the code required refactoring and has really become a lot more complicated, making it difficult to follow like spaghetti-programming, thereby requiring more and more comments, but it seems hard to avoid that. All undo/redo is carried out on the unsorted version of table so as not to loose track of which rows are being recorded/changed.
Best Regards,
/Harald