About the WPForms actions...

  • I just wonder why a choice has been made to just create a single TWPFAction with some hard-to-remember ID number that defines which action will be executed. Wouldn't it be easier to define one TWPFBaseAction class and then create all other actions as inherited actions from this base class? That way, it would be a lot easier to have an overview of all those actions.

    Or maybe just replace the ID of integer type with an ID of some enumeration type. I just don't understand why it had to be solved in such a complex way...

    • Offizieller Beitrag

    Hi,

    >>Or maybe just replace the ID of integer type with an ID of some enumeration type. I just don't understand why it had to be solved in such a complex way...<<

    Because each of this class is available in the action editor of the IDE (Add standard action)

    The procedure which is called for this actions uses a command constant - see WPFaction.PAS, procedure WPFProcessAction(Control : TObject; FormEdit : TWPFormEditor; n : Integer; Checked : Boolean);
    sou you can use your own TAction, too.

    Julian Ziersch

  • I think it's more just a matter of preferences. If you e.g. look at the Dataset-based actions from Borland, you'll notice that every action is actually it's own class. As a result, they can all have some additional action-related events and properties. By just using a single base class for everything, they all must be very similar to each other. The action lack the finer tweaking that would have existed if they all had been separate actions.

    And of course I consider the ID:integer solution to identify the action to be extremely cryptic. It means I actually have to identify an action by the name that it is given if I want to check the code. At least the use of an enumerated type would have been a lot clearer at least. Something like:

    Code
    type
      TActionID = (WPFC_NEW, WPFC_OPEN, WPFC_CLOSE, ...);
      TActionIDSet = set of TActionID;

    Now, that would provide a bit more useful functionality because Delphi will display enumerated types like this very easily. And by using constants of type TActionIDSet you can even define groups of actions that are related to each other. Or use a single TActionIDSet variable to globally enable or disable all actions. If an action is in this set, it would be disabled, for example.

    Anyway, I personally don't think the use of an integer ID isn't a pretty solution.