Question

Writing a sound control applet with GUI that communicates with a device via USB. There are several type of controls being used, faders, knobs, on/off switches. Although there are functional similarites there are often different calcualtions, ranges and settings for each, though ultimately everything gets funneled into a big structure and shipped across.

Question is this: Is there a specific pattern I should be looking at to clean this up? At present almost every control has a specific event handler that updates the main control strucure, any change in GUI appearence, and then updates the device, but it seems messy and cumbersome and I’m thinking there’s probably am established pattern for this sort of thing, but I’m not that knowledgable.

Answer 1

An architecture where every control has a “changed” event handler that updates the main structure makes sense in an application where a user can only manipulate one control at a time. If the events for each control have the same signature, then hopefully the code only has one handler method – if in the codebase each control has its own method with the same identical main-structure-updating code, then this is a good place for refactoring.

If each control has different properties and different things that it needs to do to the master structure, then this multiple-event handler architecture is perfectly sensible.

One thing that possibly doesn’t make sense is your indication that the GUI is refreshed/repainted/updated before the new control information is sent to the device. However, if the time required for both operations is miniscule, then this won’t make any difference.

Warning – mostly off-topic rant: Finally, I’m assuming from your description that the GUI is the standard looks-like-the-faceplate-of-a-rack-mounted-audio-component kind of thing. Personally, I hate these things. They look good (sort of, and sometimes), but the controls are just a pain to use.

For example, the typical knob control is manipulated by clicking on it and then dragging up and down (or right and left sometimes). This is functional (even though it’s not the way a “real” knob works), although I often find that the mouse cursor itself obscures the already-hard-to-see little black indicator line on the knob (and then I move the mouse so I can see it, which is a problem). I have used some knob controls that require a circular motion like a real knob, but these are only useful if they’re large.

The typical toggle switch control is another minor PITA, requiring you to click a tiny thing and then move it a tiny distance. One thing is typically true about the standard controls in any OS: they’re ugly, but they’re ugly for a reason, and the reason is general usability.

Finally, the whole advantage of a computer-screen UI over a real-world hardware UI is that the computer UI can take advantage of resizing and rearranging UI elements on the fly. This advantage is thrown out the window when you consciously make your UI look and act like a piece of metal or plastic (or wood grain).