- Local time
- Today, 06:29
- Joined
- Feb 28, 2001
- Messages
- 27,186
The thing about controls residing on a tab control is that they also appear to reside on the form as though you didn't have a tab control. Or at least that is how I saw it. For instance, you cannot have two controls with the same name on two different tabs on the same form. It gets a bit convoluted to try programmatically locate a control as being on a specific tab, but if your controls would ALL follow the same rules regardless of the tab they are on, I don't think it matters where they are.
Your "list of controls" might be useful for documentation, but if this list is in a table that the form has to use, you just added a speed-bump. Understand that you must do what YOU think is right and I am NOT criticizing your choice, but it is one choice I would not have made. Which is why I brought up the comments about using the .Tag property and a "For Each ctlX In Me.Controls" loop. Since the form in question has undergone the Form_Load event, all of the controls, whatever they are and however they are displayed, are already in memory. Having to consult a list in a recordset in order to display them properly adds a layer of complexity in the overhead, since every time you edit the structure of the form you have to modify the table's contents. Every time you do something on the running form you have to consult that table, and every such case involves disk operations, inherently slower than local memory operations.
One issue that came up quite often in the case-ladder based on control type was that it seemed that I also needed a nested case-ladder for the control's state-related properties like color, enablement, and visibility. But I later realized that a little abstraction helped to resolve that to two non-overlapping case-ladders. Inside the code to manage the control, I had variables for the six colors and a few other useful properties, which were the control forecolor, backcolor, and border color and the label's corresponding colors (which did not have to match the control) plus the control's visibility, enablement, and lock status, plus visibility for the label. So part one of the SetCtlState routine decided what property values to use IF the control actually HAD those properties, and the case ladder for control type then applied whichever of those properties that type of control actually had. The .Tag property contributed to deciding the correct state rules but once the state was determined, the rest of it was merely applying what was, by then, predetermined.
I don't know if that answers your question or complicates matters, but you seemed to be interested in how I would approach the problem.
Your "list of controls" might be useful for documentation, but if this list is in a table that the form has to use, you just added a speed-bump. Understand that you must do what YOU think is right and I am NOT criticizing your choice, but it is one choice I would not have made. Which is why I brought up the comments about using the .Tag property and a "For Each ctlX In Me.Controls" loop. Since the form in question has undergone the Form_Load event, all of the controls, whatever they are and however they are displayed, are already in memory. Having to consult a list in a recordset in order to display them properly adds a layer of complexity in the overhead, since every time you edit the structure of the form you have to modify the table's contents. Every time you do something on the running form you have to consult that table, and every such case involves disk operations, inherently slower than local memory operations.
One issue that came up quite often in the case-ladder based on control type was that it seemed that I also needed a nested case-ladder for the control's state-related properties like color, enablement, and visibility. But I later realized that a little abstraction helped to resolve that to two non-overlapping case-ladders. Inside the code to manage the control, I had variables for the six colors and a few other useful properties, which were the control forecolor, backcolor, and border color and the label's corresponding colors (which did not have to match the control) plus the control's visibility, enablement, and lock status, plus visibility for the label. So part one of the SetCtlState routine decided what property values to use IF the control actually HAD those properties, and the case ladder for control type then applied whichever of those properties that type of control actually had. The .Tag property contributed to deciding the correct state rules but once the state was determined, the rest of it was merely applying what was, by then, predetermined.
I don't know if that answers your question or complicates matters, but you seemed to be interested in how I would approach the problem.
