On Sep 8, 2014, at 3:55 PM, Jerry Krinock <je...@ieee.org> wrote: > Daryle, allow me to admit that I have not read much of your posts. I’m just > going to give some general advice. > > Cocoa Bindings can be problematic, but the problems are worth it when they > solve the otherwise-difficult problem of magically keeping a data model and > view in sync. In the case of NSMenu and NSMenuItem, however, there is no > difficult problem because the menu is only visible when the user clicks on > it, and at that time the delegate method -menuNeedsUpdate: is invoked, in > which you can update the menu to reflect the current state of the model. In > the other direction, the only time that the menu can change the model is when > a menu item is clicked, and at that time you get an action message sent to a > target. > > It looks like you’ve written a lot of code there. You should ask yourself > what you are trying to do with Cocoa Bindings that you could not do by > setting a delegate, implementing -menuNeedsUpdate:, and defining targets and > actions. Cocoa Bindings of menus are probably more problematic than are > Cocoa Bindings of normal view-based controls, because menus work differently. > Also, menu bindings may be more buggy since they are rarely used and thus > rarely tested.
The code takes up big space in e-mail, but it’s very little in the project. I have a controller object with notifications on the global WebHistory store. When it changes (load/add/remove/remove-all/save), the array of per-day menu items, each with a sub-menu of per-WebHistoryItem menu items, is changed to mirror the store. My application delegate has a KVO watch on that controller’s array, and changes the collection of per-day menu items put on the History menu accordingly. I have a second controller object with two arrays of menu items that possibly mirror a sub-menu of a given day-based menu item, using notifications to track changes on the sub-menu. My application delegate has KVO watches on those arrays too, accordingly changing the collection of per-WebHistoryItem menu items put either directly on the History menu and/or the sub-menu of the “Earlier Today” menu item. The method that syncs the controller for the day menu item representing Today hides the original menu item. Unhiding the menu item when Today changes but the item isn’t deleted is done in the (currently) five different spots in the code where the day list can change, customized at each spot. Using Bindings puts the visibility synchronization code in the best spot, the potentially affected menu items themselves. The KVO method came to mind first since I didn’t know about menu delegates until later. I guess with the delegate method, I save all the changes with the controllers then apply them all at once at presentation time when -menuNeedsUpdate: (or -numberOfItemsInMenu: and -menu: updateItem: atIndex: shouldCancel:) is called. With KVO, menu presentation is standard, since all the applicable items are already in place, reactively done when the WebHistory store changed. — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com _______________________________________________ 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
