Tab across controls in frames

[shg]

I have several frames on a multipage, each containing a few controls (checkboxes and option buttons). Tab order is set correctly for the frames, tabstop is False for each, and tabstops are set in the desired order within each frame.

The multipage (which may not be relevant to the problem) Cycle property is set to fmCycleCurrentForm.

The behavior I want is to tab across controls as if the frames weren't there (but the option buttons need them). As it is, if I start in the tab0 frame, it tabs through the controls as desired, but after the last control, it selects the tab1 frame and not the controls within, then the tab2 frame, tab3 frame, then back to the tab0 frame.

Thanks in advance for any suggestions.

 

[Norie]

Why do you need the frames?

Can't you use the GroupName property for the relevant option buttons?

Someone suggested some reasons why to do that instead of using frames.

• You do not have to include a Frame for each group. By not using a Frame, you reduce the number of controls on the form, and in turn, improve performance and reduce the size of the form.
• You have more design flexibility. If you use a Frame to create the group, all the buttons must be inside the Frame. If you want more than one group, you must have one Frame for each group. However, if you use GroupName to create the group, the group can include option buttons anywhere on the form. If you want more than one group, specify a unique name for each group; you can still place the individual controls anywhere on the form.
• You can create buttons with transparent backgrounds, which can improve the visual appearance of your form. The Frame is not a transparent control.

'Fraid I don't know who it was but it sounds kind of sensible to me.

 

[shg]

Norie, that never occurred to me, thank you.

My preference would be to keep the frames for appearance, but the behavior is more important. If no one can suggest how to get the behavior with frames between now and when I finish some other stuff, I'll do it.

Thank you again.

 

[Norie]

shg

I'm starting to regard frames on userforms a bit like merged cells on a worksheet - they look nice but they just seem to cause problems with functionality.

 

[shg]

Thanks for that metaphor -- I grok.

I seldom create forms -- it's just not the kind of stuff I do -- so each new one is a struggle, and this one is a little complex.

Perpendicular to the frames issue (which is untested, but solved in my mind) is figuring out how to isolate the form from the business logic in some generalized way, and nothing wonderful is popping out.

If adding this feature precludes another feature, how do you evaluate that rule in separate business logic outside the form, and then communicate it back to the form in a smoothly interactive way?

There are many, many rules ...

 

[Norie]

Well it really depends what sort of business rules you are talking about and what part the form is playing in the whole thing.

If all you need to do is refer to the options selected on the userform that's pretty straightforward.

 

[shg]

Norie, I wanted to stop back by and say thanks; your suggestion worked out great.

In addition, I figured out how to separate the app logic from the form in a very satisfying way. My form, containing some 100-odd controls across a multipage, has not a stitch of application logic in its code. Three Events Sinks (one each for textboxes, option buttons, and checkboxes, each comprising less than 10 lines of code) transport control states back to a worksheet (to named ranges that correspond to the control names), and control enable/disable state from the worksheet back to the form. All the application logic is done in relatively simple, easy to maintain formulas. Using the range names in the formulas makes their logic clear.

Thanks again.