Re: How to deal with a MenuItem with both a binded state property and an action method
Re: How to deal with a MenuItem with both a binded state property and an action method
- Subject: Re: How to deal with a MenuItem with both a binded state property and an action method
- From: "Joan Lluch (casa)" <email@hidden>
- Date: Sat, 28 Jun 2008 16:54:10 +0200
El 28/06/2008, a las 9:59, Ken Thomases escribió:
On Jun 28, 2008, at 2:41 AM, Joan Lluch (casa) wrote:
The problem remains because when the user selects the menuItem the
following happens:
FIRST- myAction is executed (possibly setting menuState to an
appropiate value)
SECOND - setMenuState is executed with a value contrary to the last
one, so if I had set it to NO in myAction, it is called now with
YES, destroying completely the intended behaviour. The menu item
then shows the wrong state in the running app.
From where is this second call to setMenuState: coming?
Put a breakpoint on it and backtrace. In Xcode's Breakpoints window
(Run > Show > Breakpoints), toggle open the breakpoint's disclosure
triangle. Click the plus button to add a debugger command. Enter
"bt" as the command. Enable the "Log" checkbox beneath the debugger
command field. Click the checkbox in the continue (▐▶) column,
so that the program automatically continues after the breakpoint
fires. With this setup, the debugger console will get a backtrace
every time your setMenuState: method is called, but it won't
annoying break the flow of your application or require you to hit
continue each time.
Cheers,
Ken
Thanks for the debugger tip, I didn't know it.
Both calls come ultimately from AppKitMenuEventHandler, although the
first one comes through "myAction" (as it is intended when it fails to
do its thing). Actually, the menuItem event handler calls "myAction"
because it is its "action", and then calls "setMenuState" because
menuState is binded to its value property. Looks all normal but
unfortunatelly if myAction sends NO to setMenuState (first call), the
following call to setMenuState (second call direct from the event
hander) receives YES and vice-versa. So the second call from the event
handler is always produced with the reverse state than the current
menu item state (this is expected) but unfortunately it is still
called after myAction has set the state, ruining the behaviour.
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.
Sure, all this can be solved by using a flag variable handling the
different cases or by directly setting the menu item state without
using bindings but I think that It should not be that tedious to do
what I intend to.
Cheers,
Joan _______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden