This fix addresses the following problems:
- fixes a bug with add: where it would try to add the sender object, not the represented object
- changes insert: to insert a new represented object after the currently selected object. If no object is currently selected it behaves like add: and adds a new object to the end.
This patch includes tests.
This fixes both the case I reported earlier (#1174) and a new issue I found where attempting to bind to a CPArrayController's arrangedObjects before calling -setContent: would throw this exception:
Uncaught CPInvalidArgumentException: Unsupported method on CPArray
The reason for this exception is that the old implementation set _arrangedObjects to an instance of _CPJavaScriptArray, whereas the new one will set it to a _CPObservableArray.
In particular the AC would fail when a _CPKeyValueCodingArray proxy was required (the destination implements insertObject:in<key>AtIndex etc.). The previous commit by cacaodev is the larger part of this fix as it enables use of mutableArrayValueForKeyPath properly. This commit merely fixes an error exposed by the previous commit where e.g. add: would apparently add two objects rather than one. This was caused by the AC observing and reacting to its own change even that it already had an optimised path to update arrangedObjects.
- make every object calling getBinding:forObject: aware of this change
- implement _CPCheckBoxValueBinder to handle binding to the value of a checkbox Closes: #1083
- re-implement CPTextField's behavior for controller markers using the new binder class
- disabled some tests that are not compliant with Cocoa
CPArray insertObject:inArraySortedByDescriptors: now quickly inserts objects at the end of the array if no sort descriptors are specified.
CPArrayController initialises its sort descriptors to an empty array.
Fixed: array controller's addObject added objects to the arranged objects array in a different order than in the content array if no sort descriptor was set.
CPArrayController was erroneously using canRemove to determine whether explicit removal could take place, when in fact the documentation for [NSObjectController canRemove] (NSArrayController does not override canRemove) states that it returns "YES if an object can be removed from the receiver using remove:, otherwise NO", implying that it should only be used to check whether there is a selected element that can be removed (for example, to bind the enabled state of a toolbar button to a CPArrayController's canRemove property). It should not be used to decide whether a specific object can be removed or not.
When initializing a CPArrayController with a value that is not an array setContent: would make it an array by replacing value with [value]. This is consistent with how Cocoa does it, but it should first check to make sure that the content is not nil. If it is, the sensible thing to do (and what Cocoa does) is to replace it with an empty array.
This commit also includes a missing import to make CPArrayControllerTest run without error.
All classes (excluding the ones prefixed with underscores) in Foundation
and AppKit can now be loaded individually except CPOpenPanel and
CPSavePanel. These two classes have some sort of dependency cycle
that seems impossible to resolve without forward declarations (which
we don't have).
It is crucial that we send notification only before and after complete changes. In the middle notifications might cause observers to see or react to inconsistent data (e.g. selection indexes pointing to rows no longer present). Added some unit tests - more might be needed in the future. Fixed: before and after values when observing array controller key paths during content changes or rearranges were wrong. Fixed: the array controller sent out multiple redundant change notifications.