[Apocalypse]

Hello,

I am currently writing a doc-based program with toolbars on the document windows. In the toolbar, there is a drop-down menu that I need to be able to modify. However, I need to modify it from the MainMenu.nib and I am not sure how. Since their should only really be one toolbar instance (since they are shared amongst the windows) I know that there would only be one instance of the menu I must modify. The tricky part is how to get access to that instance.

Would the best way to do this be instantiating a toolbar in the MainMenu.nib (bringing it's declaration into that nib, too) without any of its outlets connected and then operate on it with a controller object that connected to it and received my actions from the Main Menu?

I am really not sure.

Any ideas?
Jeff.

[Apocalypse]

Well, I decided to put the NSMenu and the view containing the NSPopupButton into an object accessible by the MainMenu.nib and then used the [NSDocumentController sharedDocumentController] method to get the controller which holds an outlet to an object that specifically oversees these two UI elements to get to them.

Although it sounds like a horrible kludge, I would have thought that it would work. Unfortunately, it only kind or works. The problem that remains is that now, when I open a new document, the previous document window loses the NSPopupButton view (being left with a labeled blank area). I can't figure out why this is happening given that the menu still remains if I change the toolbar to a text-only mode. Also, if I have the toolbar log the pointer address to the view (holding the popup) each time a new window is opened, it produces the same address each time.

I am really confused by this one and it is so close to working perfectly, now.

Any ideas?
Jeff.

[lindberg]

Actually, toolbars are indeed separate instances, not the same one. NSToolbars with the same identifier are synchronized through notifications though.

Any NSView can only exist in one place. If you add it as a subview in one view, it will get removed from whatever view it was in previously. That seems to be what's happening here.

You're going to need separate NSPopUpButtons, one for each window. Presumably they all should have the same items in them. If these can change, you would presumably store the current items in a central place, and implement the toolbar validation method to populate the pulldown with the current values (I *think* that's the best hook but I haven't played with NSToolbars too much yet -- there may be other ways). In MVC-speak this is having multiple views (the NSPopUpButtons) on the same model (the list of actions).

[lindberg]

With a quick glance at the docs, it looks like you have to subclass NSToolbarItem to do validation with a view item (which this presumably is).

[Apocalypse]

Yeah, I knew they were separate instances but I worded that statement incorrectly.

Someone on Apple's cocoa dev list told me the point you made about any given view only having one superview. My plan is to create a view for the NSPopUpButton and its encompassing View programmatically whenever a new toolbar is created and then base the contents of the new popup on an instance of NSMenu that will be shared by all documents through the NSDocumentController (using [NSPopupButton setMenu:] to accomplish this).

I will post back with more information if this plan is successful.

Thanks for your help,
Jeff.

[Apocalypse]

Yes, the idea that I discussed worked perfectly! It also allows the system to be slightly more efficient in other ways. For example, the PopUp now uses the same menu instance as the text-mode menu. This allows me to have one NSMenu which means fewer lines of code involved in the modification of the menu when it must be changed. It also yields the cool effect of having the selection on all windows change whenever any of them are changed by the user. Not only does this look pretty slick, but it will also make using the app less tedious while I work on a batch-processing feature.

Thanks for all your help,
Jeff.