[Rant] Actions …

Just a few words out of frustration: Do yourselves a favor and stay away from actions and ribbons in Delphi. At least for a while. If you really need fancy looking menus use JEDI.

P.S. This would be a follow-up of this post I’ve written last September.

You May Also Like

About the Author: Alexandru Ciobanu

9 Comments

  1. Why don’t you go into a little more detail – you’ll either get help or confirmation of the issues. As it stands, your rant helps no-one, yourself least.

    I have used ActionManager, Menus and Toolbars since D6 very successfully. And the new Ribbon works fine for what I’m doing.

  2. 1. There are bugs in action client items and ribbons handling those. (play with CommandStyle/Properties)
    2. Try to build a more complicated menu using the action manager + action main menu.
    3. Try to control that menu by disabling sub-menus and etc.

    You would then understand the problem. It is possible to work around the problems but I don’t think its worth it yet.

    P.S. I mentioned in the post it’s “out of frustration” (mine) 🙂

  3. What are the issues you are encountering?
    How is this post supposed to help people out?

    Why not document the issues you are seeing and then the issues can be addressed.

    1. What are the steps for these issues?
    2. What is a complicated menu? The Delphi IDE is a pretty complicated menu and it uses the ActionManager.
    3. So do you want to disable the menu item that controls the sub menu, or you want to disable the sub menu items?

    Disclaimer: I wrote the Ribbon controls for CodeGear so am interested in all feedback, even though I am no longer maintaining it.

  4. OK, I should have put a “Rant” in the title. This post wasn’t really supposed to be useful in the first place. But to answer your questions:

    1. TActionMainMenuBar — If you build it visually, you will probably get an AV sooner or later. But I guess people are used to it already.

    2. TActionMainMenuBar — Try creating a menu which has a sub menu and etc. You can’t really disable a whole menu. Anyone can press the ALT+shortcut or select an activated menu item and the using the keyboard go to the disabled menu. This makes it really hard to port application which disable only the “Edit” menu item and not it’s sub-items. You can get to those items pretty quickly. (Example: go into the IDE and go to the Translation manager using the keyboard. Even if the menu item is disabled, press enter and a sub-menu will be displayed, note that those 2 options in the submenu are enabled and can be clicked! Even if you’re not allowed to do so.)

    3. I tried to find a way to disable menu items without assigning bogus actions to categories-generated action client items. It seems no underlying control is created for items in submenus which makes it impossible to do so.

    4. Ribbons — Put an action onto a ribbon group. A new action client item will be generated. Set it’s CommandStyle property to csCheckBox. Then, if you’re lucky, CommandProperties should be set properly or an AV happens (for obvious reasons in the code). So the handling of these properties is very ugly.

    5. Ribbons — again, most of CommandStyle/CommandProperties are not yet handled (thus the “stay away from the ribbons for now”). You may be really disappointed if you think something will work and it won’t.

    NOTE: Ribbon issues are reported and being worked on so no worries there.

    P.S. Note to myself: next time add more useful information 🙂

  5. I’ve encountered some problem running (I didn’t modify it at all – just SHIFT + F9) the Ribbon demo app provided with RAD D2009:
    Sometimes, the icons/actions/buttons (?) will be disabled (“Themes”) after changing the theme.
    Sometimes, the text attribute icons/actions/buttons (?) will almost “disapear”…
    I didn’t try to debug and find out what’s going wrong, though.

  6. 1. Not something I’ve experienced but I’m sure you posted the crash reports to QC.
    2/3. So instead of disabling the individual actions contained in the sub menu, you want to disable the parent item for the sub menu. It doesn’t work like that, but that doesn’t make it a bug.
    4. Interesting. The only time I see an issue when changing CommandTypes is when the CommandProperties property is expanded in the object inspector and the object inspector raises exceptions when trying to redraw the OI. Feel free to point out the code you think is the cause via email.
    5. Most is a bit of a stretch. Apart from in ribbon galleries, what properties are not currently supported? These items were included as they may have been enhanced in an update instead of waiting for a new release.

  7. Further to items 2 and 3 your design is just wrong.

    You are using actions. You should disable the action itself. Not its parent menu. It makes no sense (to disable the parent menu) because what if you used that action on a Toolbar. Do you expect the toolbar command (which points to the same action) to be disabled when a sub menu is disabled.

    Just write OnUpdate events for your actions.

  8. 1) For disabling the actions: I was referring to the fact that old applications which depend on disabling whole menus are quite hard to port over. And in fact when using normal menus, disabling the whole Edit menu saved quite some typing.
    — And I still don’t agree with the fact that a sub-menu can be selected even if it’s disabled. That just seems wrong to me.

    2) Ribbons – that’s why I said: stay away from ribbons, at least for a while. This actually meant what was written — Not everything is ready so don’t use it — you might be disappointed.

    Example: CheckBoxProperties.Width; When you switch over to ControlProperties, the ctor sets the Width to -1 which makes that client item of 0 size and you cannot the select it properly.

    All in all, most of the real problems are in design mode and not at run-time.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.