handling GUI element properties per app state

Question

I was thinking of centralizing this functionality by having a single method that gets passed an AppState argument and it deals with changing the properties of all GUI elements based on this argument. Every time the app changes its state (ready, busy, downloading so partially busy, etc), this function is called with the appropriate state (or perhaps it's a bit field or something) and it does its magic.

If I scatter changing the state of GUI elements all over the place, then it becomes very easy to forget that when the app is in some state, this other widget over there needs to be disabled too, etc.

Any other ways to deal with this sort of thing?

Answer 1

Yes, this is the most time consuming part of the GUI work, to make a user friendly application. Disable this, enable that, hide this, show that. To make sure all controls has right states when inserting/updateing/deleteing/selecting/deselecting things.

I think thats where you tell a good programmer from a bad programmer. A bad programmer has an active "Save"-button when there is nothing changed to save, a good programmer enables the "save"-button only when there are things to save (just one example of many).

I like the idea of a UIControlstate-handler for this purpose.

Me.UIControlStates=UIControlstates.EditMode or something like that.

If having such object it could raise events when the state changes and there we put the code.

Sub UIControlStates_StateChanged(sender as object, e as UIControlStateArgs)
   if e.Oldstate=UIControlStates.Edit and e.NewState=UIControlStates.Normal then
      rem Edit was aborted, reset fields
      ResetFields()
   end if
   select case e.NewState
       case UIControlStates.Edit
         Rem enalbe/disable/hide/show, whatever

       Case UIControlStates.Normal
         Rem enalbe/disable/hide/show, whatever
       Case UIControlStates.Busy
         Rem enalbe/disable/hide/show, whatever
       Case Else
         Rem enalbe/disable/hide/show, whatever
   end select
end sub

Answer 2

@Stefan:

I think we are thinking along the same lines, i.e. a single piece of code that gets to modify all the widget states and everyone else has to call into it to make such changes. Except, I was picturing a direct method call while you are picturing raising/capturing events. Is there an advantage to using events vs just a simple method call?

Answer 3

Emrah,

Your idea is good. You need to limit the state structure and this is the only way to ensure reliable UI. On the other hand do not follow the "one function" idea to strictly. Rather continuously follow its direction, by creating a function and then do progressively refactoring all attributes to a single "setter" function. You need to remember about a few things on your way:

1. Use only one-way communication. Do not read the state from controls since this is the source of all evil. First limit the number of property reads and then the number of property writes.

2. You need to incorporate some caching methodology. Ensure that caching does not inject property reading into main code.

3. Leave dialog boxes alone, just ensure that all dialog box communication is done during opening and closing and not in between (as much as you can).

4. Implement wrappers on most commonly used controls to ensure strict communication framework. Do not create any global control framework.

5. Do not use this ideas unless your UI is really complex. In such case using regular WinForms or JavaScript events will lead you to much smaller code.

6. The less code the better. Do not refactor unless you loose lines.

Good luck!