Dropdown arrow for CMenu


I am using CActions on my dockables as follows:
-CButtons for „leaf“ actions;
-CMenus (with potentially nested CMenus) for actions which require a dropdown-menu.

So far so good.

But I wanted to visually distinguish between the two types of actions above, so that the user can predict whether clicking on the CAction will directly trigger some action (type 1), or show a dropdown-menu (type 2).

So I was hoping CMenu comes with a drop-down arrow, just like CDropDownButton does.

Now, the answer to „why don’t you just use a CDropDownButton then??“ :slight_smile: is that I don’t want the „last-action-saving“ feature of CDropDownButton.

So is there a way I can turn off this „last-action-saving“ feature in my CDropDownButton so that it behaves exactly like a CMenu but with a drop-down arrow?

Or maybe you have other suggestions to achieve this?

Thanks a lot,

Most actions are a subtype of CDropDownItem. CDropDownItem offers some methods to define the behavior of an action in a CDropDownButton, one of them is “setDropDownSelectable”. If this property is false, then the action should never be automatically selected by the CDropDownButton.

Thank you Beni!

Setting the „dropDownSelectable“ property of the contents of my CDropDownButton to false does the trick.

Thanks! :slight_smile:

Hi Beni,

After reconsidering the option of using a CDropDownButton and setting the „dropDownSelectable“ property of its contents to false, I realized that it is not really the best option for me.

The thing is with „last-action-saving“ feature removed, a CDropDownButton „becomes“ nothing „more“ than a CMenu, except for the drop-down arrow. And hence the only reason for me to use a CDropDownButton is its look (the extra drop-down arrow it has).

But since I need to use CMenus anyway for second-level (nested) menus, my code will contain both CDropDownButtons (for first-level menus) and CMenus (for nested menus), and this is causing some duplication in the code I apply to menus just because not all of them are of the same type.

So it would be best if I can use only CMenus (for first-level menus and beyond), and currently my only obstacle to do that is the fact that CMenu doesn’t appear with a drop-down arrow.

So could you possibly modify the look of CMenu to have a drop-down arrow too?
Actually regardless of everything I said above, it would be really useful, for everybody I guess, if CMenus had drop-down arrows, to help distinguish them from non-droppable CButtons. :slight_smile:


You can use CDropDownButton for the nested menus. If the button is part of a menu, it’s behavior becomes identical to a CMenu.

[Edit: … and with 1.1.1p6b this solution won’t even throw an exception anymore … ]

About CMenus with or without arrows: but then you could not distinguish CMenus from CDropDownButtons… the way it is now all options are open (especially since you can use CDropDownButton as CMenu with arrow), if I would add arrows to CMenus I would actually remove a feature.

Hi Beni,

Well OK I don’t mind using CDropDownButtons for both first-level and nested menus to solve my “duplication” problem and get the “arrow” look, but the thing is when I once tried to add a CDropDownButton inside another CDropDownButton, I had some problems, that’s why I dropped that option.

Attached is a modified version of an example you posted at: http://forum.byte-welt.net/showthread.php?t=3729
I added code to have nested CDropDownButtons. You can see that as soon as you want to do something with the dockable (like move it, or minimize it, or select/unselect it, etc.), you get the attached exception.

Thank you,

Yes, I’ve seen that exception yesterday as well. Hence my comment “[Edit: … and with 1.1.1p6b this solution won’t even throw an exception anymore … ]”. I have some trouble testing all the different combinations and methods that can be used, and as a result bugs like this one can slip through. This bug existed since months, and you seem the first one to find it (or the others just didn’t tell).

Still, if you see any exception, send me the stack trace. The framework should not throw any exceptions (except those where the failure is in the client, but then the error message should tell exactly what is wrong).

:o Ohh… now I see the „[Edit: … and with 1.1.1p6b this solution won’t even throw an exception anymore … ]“. The first time I saw it, I didn’t really understand, and I thought it was pasted by mistake from some other post, so I just ignored it. :smiley:

Great then! Looking forward for 1.1.1p6b! :slight_smile:

Thank you Beni,