El 28/06/2008, a las 18:44, Keary Suska escribió:
6/28/08 8:54 AM, also sprach [EMAIL PROTECTED]:
To sumarize, the problem is that I am not able to change the menuItem
state programatically (ie. in myAction) without avoiding the second
call to setMenuState. However if the call to myAction comes from a
button set up in IB (instead the menuItem), then everything goes ok.
In that case myAction is called by the click of the button and if the
state of the menuItem is updated by myAction then it is correctly
changed. No second call to setMenuState is received because the
originating event came from the button. On the contrary if the event
originates from the menuItem, first myAction is called, and then
setMenuState is called.
With controls, the bound value is changed *before* the target-action
is
called, as you are seeing, but it seems NSMenuItem does the
opposite. If the
calls are sequential--i.e. without a call to the run loop--you could
use
performSelector:withObject:afterDelay:to make the setMenuState call.
Thanks, I am not absolutely sure because I did several changes in my
project but I think that this can be considered a bug of 10.5 sdk,
because it started to happen when I started to compile for it. The
(almost) same project when it was targeted for Tiger always changed
the bound value *before* the target-action was executed, regardless if
it was a button or a menuItem. Apparently this consistency has been
broken in Leopard. I may post a bug report after some testing to
confirm it.
Joan Lluch._______________________________________________
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 [EMAIL PROTECTED]
