Toggling UI Command Status? RRS feed

  • Question

  • I have a question.  In our application shell, we have a tree view of actions that contain a list of commands that can be performed.  These commands need to change their enabled/disabled status when certain "perspectives" or views are shown, in addition to being already filtered initially by user roles.  Furthermore, the actions can be filtered by a selection of what depth level in another tree view is selected.  I'm currently trying to implement this functionality in a SCSF CAB-style application using actions.

    I'm a little confused as to how this might be implemented right now in a way that is maintainable and not putting all this functionality into a single winform and performing all the filtering logic in a single module.  I am learning about how to develop winform applications, so this is a learning experience for me.  I'm trying to do it the way it should be done.  Ideally, each command in these tree views will invoke a command using the command design pattern.

    Any help would be appreciated.

    Wednesday, August 8, 2007 3:53 AM


  • Specifically in CAB you can use the Event Broket to implement what Diego talks about

    Wednesday, August 15, 2007 12:19 PM

All replies

  • Shemazar,


       I guess your scenario looks propicious for the Observer design pattern (you may read about it here: http://msdn2.microsoft.com/en-us/architecture/ms954621.aspx)


       Basically speaking you may split the logic of your application in the following way: the WinForm application, upon user selection on menues, etc, will fire events


       Another assembly must have been registered as observer of those events, launching the propper tasks. In this case, as I see it, the proper tasks imply having a list of delegates (I'm just guessing as I don't know the context of your application). So one delegate could take care about actions related with the Payments module, enabling/disabling thus those related actions. Another delegate could be related with Purchases module, and so on


       That way, the form could be in an assembly, the observer could lay in another assembly, and each delegate could belong to a separated assembly (related to their modules). The observer must register itself with the form during the startup. The per module delegates may be wired to the observer via config files/reflection mechanisms

    Tuesday, August 14, 2007 9:07 PM
  • Specifically in CAB you can use the Event Broket to implement what Diego talks about

    Wednesday, August 15, 2007 12:19 PM
  • Hi,

    Good question! I've just had to do something similar. Heres a brief summary.

    My approach was to mimic the ui Action concept. (delphi,swing,smallworld etc). Basically a single Action class encapsulates the data about its widget presentation. Client application instantiates Actions and stores then in an ActionManager class (either by specific or default category). Application build the widget(s) based on the Action definition. Another class ActionController handles the Component widget registration and bidirectional lookups between each action and all associated Components. The controller wires up the event handlers for each component and vice-versa on shutdown. ActionController intercepts the enabled property event for each action and toggles the ui status of all widgets accordingly. Invocation of the business logic is pure Command pattern. The Command implementation being stored as a field on the Action

    Benefits to my current project are: the UI is built programatically ( I hate wasting my time with that pissy ui designer), ui widget encapsulations are easily passed between different plugins in the application at runtime, All ui widget toggling is done in one place. The widget presentation code is defined separately from the business logic so designers and developers can in theory coexist. From here it is one simple step to xml storage of the action definition and xml based ui configuration.

    hope this helps

    Monday, September 10, 2007 5:21 AM