Setting menu Item as Ticked


Hi ,
I have menu bar and each menu has sub menus . I have to perform different actions on different submenu selection . I am able to perform action But my problem is I want to set the submenu as ticked and when anthoer sub menu item is slected I want to de tick the previous ticked menu . How to do this ?


If you don’t want a menu item to be ticked, just don’t set the isTicked parameter when you create it.


Yes, how do you set the tick(check mark) to an item that has already been added to the popupmenu. Need this badly.


This is possible by iterating the sub menus and comparing each item of submenu with the actual selection.
Then then add the sub menu to main menu.
Hope that makes sense…
Works here for files. Not sure if it’s applicable to what you need though.

		PopupMenu subMenu;	        // Main menu which will contain everything else
		mainMenu.clear();		//initialize menu
		PopupMenu subMenu;		// new submenu

		int howMuchItems = 0;
		int ID = 0;				// ID number in returned by menu
		bool isTicked = false;		// default state is unticked
		for (int i = 0; i< fileArray.size();i++)				//read TTD_IR array
			ID++;									// increment ID for the popmunu
			String IDName = fileArray[i];				// retreive from file array
			if (nameDisplayed->getText() == IDName)		// isTicked if one of the file inside match the currently loaded file
			  isTicked = true;													
             subMenu.addItem (ID, IDName,true,nameDisplayed->getText () == IDName);	// add items to subMenu
            mainMenu.addSubMenu("Sub Menu 1", subMenu,true,Image::null,isTicked);	// Then add subMenu to mainMenu



Thanks but that is not what I need. Here is simple description.

A popup menu has four items added. After adding the menu items, I want to (tick/check) the third item. No sub menus needed. I do not want to (tick/check) it on the fly as the items are added. I need to add the check mark after the whole menu is built.


You can use commands?

getCommandInfo () or similar lets you check and check menu items.



Thanks but this is not what I need. My menus are not assigned individual command IDs and therefore the applications cannot use this method. I need a way to set the check mark locally. There must be a better way than this. Why is there not a popupMenu.SetCheck( int nItem, bool true ) type of command. Every environment but juce has this.


PopupMenu objects are not designed to be kept hanging around or to have their content changed - you create one that contains whatever items you need, use it to tell the system what you want, and let it go. That’s why they don’t have many modifier methods.

…and it’s non-trivial for you to simply tweak the code to find out which items are checked on-the-fly?? Wow, must be quite a plate of spaghetti you’ve got there!



Not the answer I was hoping for. The problem is for those who are porting code to juce. Both Mac and PC have member functions similar to the MFC function CMenu::CheckMenuItem( UINT nIDCheckItem, UINT nCheck );for existing menus. So if existing code is to be ported, everywhere menus were created ahead of time and the flags were set afterwards, the whole function and logic has to be rewritten to accommodate the juce way of handling menus items. This may be fine if you’re writing a program from scratch, but not if you’re porting. My code is not spaghetti, it’s very portable between Mac and PC, but not when porting to juce because of it’s restrictions. I have three major music applications ( both are on PC and MAC ) still in existence after 20 years, so obviously I’m doing something right.

A simple rule for providing safe cross platform code with access to member variables that could break the code is to make the member variables private and provide member access functions. This gives safety and flexibility. Looking at the juce PopupMenu routines, it would be simple to do this. So for a typical routine like PopupMenu.setItemCheck( int itemId, bool bChecked )Write a simple loop that gets the item (pItem) from the OwnedArray, by comparing pItem->getItemID() to itemId parameter to get the desired item and then call pItem->setItemCheck( bChecked). Flexible and extremely safe code. Do this for all the variables and the users will not be restricted to doing it only the juce way. This is what Apple has been doing over the years. Making the code safer and giving access through access functions. You did this in the Point class, which I felt was not needed because direct access can not break a Point class but not in the PopupMenu class where it is needed.

Hope this is helpful. I implemented this in juce for the fun of it, but don’t want use it because of maintaining juce updates. Hopefully you’ll consider this. Finally It will not break any existing juce applications because most of the item variables were declared const. If you wish I’ll provide the code.

Please don’t get me wrong, I think juce implementation is very good, but I think the user experience could be improved to make it great, even better than Qt.


[quote]So if existing code is to be ported, everywhere menus were created ahead of time and the flags were set afterwards, the whole function and logic has to be rewritten to accommodate the juce way of handling menus items. This may be fine if you’re writing a program from scratch, but not if you’re porting.

Yeah, and I sympathise, but Popup menu was never intended to be a replacement for CMenu!

Sure, I could add a method to set the tick state… but then for completeness it’d also need methods to set every other property of each item, and that’s a whole bunch of bloat that I don’t want in the class. In fact, what it needs is a Menu::Item class to contain all the item’s properties, which would make this all possible with minimum fuss - that’s something I’ve been meaning to do anyway, but will require a few hours of refactoring, and can’t promise when I’ll get chance to do it.



Thank you for considering it. An easy approach, is to put the member variables in a struct and get and set the struct, but I prefer your idea of an Item class with the members and functions to access and set them. Now everybody porting from previous systems will not have to rewrite their code. The CMenu way provide opportunities to do it the juce way or any way the user chooses. Hey CMenu handles the main menu bar and popup menus with basically the same calls.TBH, some of my code does build menus on the fly like juce and some of the code creates the menus at the start of the program.

As for members, isTicked, isActive, and itemId, are the main ones most would use anyway.

I’m glad you’re seeing where my frustration is coming from. It’s not that juce can’t do what I need, because it can. It’s that I have to define my own class to handle the things that were handled by MFC and Carbon (now Cocoa). My code has 15-20 years of MFC/Carbon(Cocoa). BTW, Cocoa is driving me nuts as I’m sure it did you when rewriting. Hey that’s one of the main reasons I considering juce.

I can send you the code( fully debugged and tested) if you wish.

Thanks again