On Mon, 03 Nov 2008 08:58:20 +0100, Alexander Reichstadt <lxr...> said:
> I found something really odd just now. The searchmenu is actually
> connected to an IBAction method. The NSLog sits in there and simply
> prints out the sender, i.e. the menuItem that triggered it.
>
> If I change the menu item in the UI the NSLog printout shows that it's
> another part of memory that triggered it as if I trigger the
> searchaction through my code, so the objects are not identical. It's
> not that I instantiate more than one menu
Yes, it evidently *is* that you instantiate more than one menu. Or at least
it's that you change what menu mySearchMenu (or some other pointer along the
line) is pointing to. Now you have to figure out how.
> , so it's not clear to me
> where the other menu-twin with the same menuItems comes from. When I
> try to retrieve the menu through the NSSearchFields cell-menu, it's
> empty. This makes me wonder where the menu is actually stored and how
> many instances for whatever purposes are kept alive under the hood. I
> definitely only know of one NSMenu instance referenced through one
> IBOutlet which should be the one attached to the NSSearchField, but
> somehow I end up with two at runtime.
This kind of thing can be caused, for example, by having an outlet called
e.g. myOutlet and a method called setMyOutlet:. Is that your situation?
I must say, however, that your debugging approach here is excellent. In your
first message, where you say that the menu stopped working after one use, I
was going to suggest that the reason was that you were accidentally
generating another menu and that mySearchMenu was no longer pointing where
you think. But you discovered this very fact for yourself - well done. m.
--
matt neuburg, phd = <matt...>, <
http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
One of the 2007 MacTech Top 25: <
http://tinyurl.com/2rh4pf>
AppleScript: the Definitive Guide - Second Edition!
<
http://www.amazon.com/gp/product/0596102119>
