- Local time
- Yesterday, 22:37
- Joined
- Feb 28, 2001
- Messages
- 27,302
Something like what you posted, but also look at what Arnelgp proposed in post #9 of this thread. For those things that use the same criteria, compute the common value first in a simple variable local to the routine and then assign that value to all the cases that use the same rules. Makes for a LOT less code and is easy to understand when reading.
There is no way for me to know that, but perhaps I can give you a guideline. Normally, the individual "click" events seem to trigger some kind of visibility change for you. So you need to lay out on paper some kind of rules that are imposed by each such click event. (This is a bit tedious but can't be helped.) Now gather like rules together based on which click does which job. For those events that use the same exact rules each time regardless of which of your controls is clicked, they can call a common routine that has the same effect. If there are differences in effect, then you need routines that recognize the differences. Your routines APPEAR (from our end of the telescope) to be duplicating effort in a way that makes it hard to know which controls will and which controls won't become visible. (I.e. as you point out, visibility becomes a problem of inconsistency.) There is NO substitute for this... step away from the code and lay out some kind of "map" that tells you what each click is supposed to do if taken in isolation. Group all that are alike. Apply what arnelgp and I have told you about code structure to minimize typing AND clarity.
You would use individual click events based on your users clicking individual controls.
When you use the LOAD event for the form, you would set the visibility to whatever is its default position. One routine that sets visibility would do the job. But... if this is a bound form, you don't need a LOAD event because you are about to execute a CURRENT event that is a far better. It will have values in all of the bound controls and you can run the "global" changes ONCE (per CURRENT event) there. Then let the individuals do their jobs. That comes down to ONE (and only one) event routine to address ALL of the controls, plus your individual click event routines which might affect fewer controls. There is this philosophy that many of use espouse - KISS. I'll keep it clean... Keep It Simple, Silly.
Do I do this for all of the on click events? then Call those events Load and Current?
There is no way for me to know that, but perhaps I can give you a guideline. Normally, the individual "click" events seem to trigger some kind of visibility change for you. So you need to lay out on paper some kind of rules that are imposed by each such click event. (This is a bit tedious but can't be helped.) Now gather like rules together based on which click does which job. For those events that use the same exact rules each time regardless of which of your controls is clicked, they can call a common routine that has the same effect. If there are differences in effect, then you need routines that recognize the differences. Your routines APPEAR (from our end of the telescope) to be duplicating effort in a way that makes it hard to know which controls will and which controls won't become visible. (I.e. as you point out, visibility becomes a problem of inconsistency.) There is NO substitute for this... step away from the code and lay out some kind of "map" that tells you what each click is supposed to do if taken in isolation. Group all that are alike. Apply what arnelgp and I have told you about code structure to minimize typing AND clarity.
You would use individual click events based on your users clicking individual controls.
When you use the LOAD event for the form, you would set the visibility to whatever is its default position. One routine that sets visibility would do the job. But... if this is a bound form, you don't need a LOAD event because you are about to execute a CURRENT event that is a far better. It will have values in all of the bound controls and you can run the "global" changes ONCE (per CURRENT event) there. Then let the individuals do their jobs. That comes down to ONE (and only one) event routine to address ALL of the controls, plus your individual click event routines which might affect fewer controls. There is this philosophy that many of use espouse - KISS. I'll keep it clean... Keep It Simple, Silly.