But depending on an undocumented feature of the MacOS-X implementation of NSMenu ...
you are expecting the menu to be destroyed when you release it, and that might not be so.
The code may not work in the next release... it may even (depending on how NSMenu is
actually implemented) not work sometimes in your own application ... since you don't know
under what circumstances the menu is actually deallocated ... perhaps the system may
decide to store it in a cache for some time under some circumstances.
Isn't the 'correct' code to move the item from one menu to the other like this ....
- (void)methodForContextMenuExample { NSMenu *menu = [[NSMenu alloc] initWithTitle:@"bip"];
[menu addItem:menuItem]; [menu removeItem:menuItem]; [menu release]; menu = [[NSMenu alloc] initWitTitle:@"hop"]; [menu addItem:menuItem]; }
All that being said ... I like GNUstep implementation details to be as close to MacOS-X
as we can reasonably manage ... so if NSMenu *seems* to never retain itsself, it would
be nice if the GNUstep implementation did the same, but that's not a reason to invent a
rule about memory management which does not exist in MacOS-X, nor is it a reason to
write user code which depends on undocumented features of the system... it's just a
user friendly practice to cope as best we can when user code does make bad assumptions.
Ok. Well said, I'm convinced. I see where is the problem with my assumption now. Sorry for the rule story ;-).
I will rework my code.
Thanks, Quentin.
-- Quentin Mathé [EMAIL PROTECTED]
_______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
