On 08/08/2009, at 10:01 AM, David M.Cotter wrote:
the problem is i'm stuck with a very large legacy code base that i
must modify minimally to shoehorn into Cocoa. this same code must
cross compile on windows, so i can't change the underlying
architecture, which has for a decade now relied on the fact that we
can share submenus across many super-menus.
Well since Cocoa can't be compiled/run on Windows, presumably you have
some separation of code bases for Mac and Windows. So there's no
reason you have to stick rigidly to the same code on both.
what seems to work at the moment is doing this:
[subMenu setSupermenu:NULL];
just before setting it AGAIN as a sub menu to another super menu.
i am quite sure i'll need to do some shenanegans to avoid over-
releasing when we dispose our menus, but for now it seems to be
working.
does anyone feel the universe will explode in my face by doing this?
I'd say this is definitely going to be fragile. You can't know how
those relationships are expected to work internally, so yes, it could
blow up in your face - if not today, then in a future release. Do you
really want a thousand support calls one day saying "I upgraded to
blah and your app broke"?
I still think you should do it the Cocoa way, as far as possible.
Note though, that NSMenu conforms to NSCopying, so you could easily
make as many copies of the same menu as you need and make each one a
distinct instance. Validating items on the fly which is the supported
way means that you do not need to manage all of these as a large
collection - wait for the user to show the menu and update it then.
Since only one menu can be shown at once this is inherently efficient,
and likely to be much more so than whatever your app is doing now (if
it's doing something much different, it's missing a trick with respect
to performance - lazy is best; updating all possible, yet invisible,
menus on a state change is a huge waste of time).
Another alternative, if you really can't face doing it properly, is to
hook into the "menu about to be shown" notification for the parent
menus, and attach the submenu on the fly at that time.
--Graham
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
