William Benson (VBACreations.Com)
vbacreations at gmail.com
Sat Aug 27 15:10:03 CDT 2011
John, I think what is really important is to make sure what you build is stable and predictable, but doesn't act too clunky or invite the user to screw themselves. You will humiliate them, and they will think it is your fault if you make it too easy to make an error -- just as much as they will whine if you make them go through too many confirmation steps. I like to make data areas expand and move controls out of the way - so I tend to group controls across the top and near the right, in rectangular areas. I reposition things on resize. I like command buttons to be of uniform size if possible, which is hard to set when the captions change. So I use a process of putting a label on a hidden form, throw all similar command button captions into it, get the max width that causes, then use that value to adjust all the command buttons from a certain area on the active form. If the same unbound controls are required to be displayed to the user on many separate forms so that those values are knows whatever the user is doing -- and if they take a particularly long time to calculate -- I have found it necessary to create a convenient means of calculating once, so they can be shown in many spots. Those "calculations" involve recordset related computations, for example - slow stuff, relatively speaking. Along the way I came up with the idea of using a hidden form to keep a base set of controls, which is always open, and then letting the control source of controls on other forms be bound to those base controls. Honestly I don't know if that has worked out well or not. It is certainly faster than keeping all recalculation activity local to every form... but I do wonder if I might have done just as well using public functions and global variables to hold the recalculated information. When it comes to double-click event. As a programmer and power user, who can fix anything that goes wrong in the tables - I love it. But as a user who "accidentally" double-clicks the wrong record, item, control -- or didn't mean to double-click at all, sometimes the programmer gets blamed for the result of their spasmodic gestures. But if you mitigate this risk by making them confirm their intentions, they get upset with that. So I tend to not confirm deletions, but I require them to hit the button marked DELETE ... and if there are more than one type of thing on a form which can be deleted, I keep a separate delete button next to each control with data that can be deleted. One item I have not been too sure about and don't mind asking -- what do people think of buttons with + or - as a caption. In a group of values I would think that automatically means Add or Remove, but some users might think it means expand and contract the list. Save ... now there is a sort of a problem. I confess I take the easy way... every change is saved. Want it back again, change it again. Good topic, by the way. I wish we as a user group would have a sort of online symposium to show off examples of what we are doing and (if our skins are thick enough) get feedback from one another on what we like and don't alike about what we see. Bill