Main form with many tabs and subs

[Jack Leach]

Hello all, and thanks in advance for any insights.

Some time ago I saw an application (not access) that was set up with one
main form that the user was always on, which had many different levels of
tabs. The vast majority of tasks within the app were done from this mainform.

The tabs were positioned so the Top Level of tabs was your main portions of
the app: Purchasing|QC|Quoting etc. When Purchasing was selected the next
'level' (right below it) was another tab control containing various tasks to
purchasing. Sometimes this would layer 4 or 5 tab levels deep.

I thought this was a great interface to allow users quick very quick access
to all corners of the app (or at least all the common ones). The 'tab
levels' take up a menu-bar or three height at the top of the form on average,
with ample space below for controls/subforms etc.


I do not expect the integration and refreshes between one tab to the next to
be much of an issue (I'm fairly certain I can make it work), but I am looking
for ideas in the best way to approach this from a performance perspective (or
testimonial that access can't efficiently handle this type of setup).

I've read on late-binding of forms, and am considering loading this entire
mainform as part of my app startup (I don't mind a delay for loading at this
point), in which case I should hopefully be able to efficiently set the
required format and properties (late bind) each tab page after the user logs
in.


So I guess my real question is this: Has anyone attempted an interface like
this before and can tell me whether I'm on the right track or not (any
thoughts on it really would be helpful).

Ideally I can have delay on the app opening, a slight delay on the user
login process, and minimal delay when switching from one 'Top Level' tab to
another, and have everything else flow as quickly as possible.

Sorry for the long post... hopefully I've explained the setup understandably

THanks!!


--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[Tom van Stiphout]

On Sat, 9 May 2009 05:45:02 -0700, Jack Leach <dymondjack at hot mail
dot com> wrote:

You can accomplish this with nested tabs. You would have to put
subforms on the tabs, and if you have more than half a dozen or so you
would want to postpone loading those subforms until the tab is
accessed. That's done by setting the SourceObject at the last possible
moment.
I think a carefully designed Ribbon offers a superior UI.

-Tom.
Microsoft Access MVP

 

[Tom van Stiphout]

On Sat, 9 May 2009 05:45:02 -0700, Jack Leach <dymondjack at hot mail
dot com> wrote:

You can accomplish this with nested tabs. You would have to put
subforms on the tabs, and if you have more than half a dozen or so you
would want to postpone loading those subforms until the tab is
accessed. That's done by setting the SourceObject at the last possible
moment.
I think a carefully designed Ribbon offers a superior UI.

-Tom.
Microsoft Access MVP

 

[Jack Leach]

Thanks Tom.

I'm unfamiliar with the ribbon (that is 07(?) and I'm on 03), but I do have
a great menubar that about half my users utilize. The other half is rather
computer illiterate, so I am attempting this nested tab idea in an effort to
makes things just as quick visual navigator for those who don't know to use
alt and arrows/characters to find menus. My plan is to convert the existing
menubar into functions to nagivate the correct tabs rather than opening
individual forms as they currently do.

I may be looking at 50 to 100 subforms by the time I'm done nesting all of
the tabs, and maybe twice as many controls in the main form. I would plan to
bind all these late. This shouldn't be too much for Access to load into
memory and keep there until the app closes, right? I'm not sure the kind of
performance effect that overhead would have on an average computer. Is it
plausable to un-bind subforms if I go from one top-level tab to another for
overhead reduction when not in use? This may be able to keep the open
subforms at 5 to 10.

Sorry, lots of questions, but this would take forever to test. Nice if
someone already knows.

Thanks for the input.
--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[Jack Leach]

Thanks Tom.

I'm unfamiliar with the ribbon (that is 07(?) and I'm on 03), but I do have
a great menubar that about half my users utilize. The other half is rather
computer illiterate, so I am attempting this nested tab idea in an effort to
makes things just as quick visual navigator for those who don't know to use
alt and arrows/characters to find menus. My plan is to convert the existing
menubar into functions to nagivate the correct tabs rather than opening
individual forms as they currently do.

I may be looking at 50 to 100 subforms by the time I'm done nesting all of
the tabs, and maybe twice as many controls in the main form. I would plan to
bind all these late. This shouldn't be too much for Access to load into
memory and keep there until the app closes, right? I'm not sure the kind of
performance effect that overhead would have on an average computer. Is it
plausable to un-bind subforms if I go from one top-level tab to another for
overhead reduction when not in use? This may be able to keep the open
subforms at 5 to 10.

Sorry, lots of questions, but this would take forever to test. Nice if
someone already knows.

Thanks for the input.
--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[Jack Leach]

On second thought, the more I play around with this the more I'm realizing
that I'm going to be fraught with formatting related difficulties to get
exactly what I want for asthetics out of this.

I'll look into improving on my current 'sidebar' setup. As nice as the tabs
would be I don't think I quite have the required time to devote to it.

thanks
--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[Jack Leach]

On second thought, the more I play around with this the more I'm realizing
that I'm going to be fraught with formatting related difficulties to get
exactly what I want for asthetics out of this.

I'll look into improving on my current 'sidebar' setup. As nice as the tabs
would be I don't think I quite have the required time to devote to it.

thanks
--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[tina]

well, it sounds like it would pretty complex to work through - at least
mentally - but could be pretty cool when done. one thing to keep in mind
with tabs is that the user can only see one page of a given tab control at
any point in time. one way to keep down the clutter is to put a single
subform control *behind* the tab control, so the subform "shows thru" on all
pages; then assign an appropriate SourceObject to the subform each time the
"current page" of the tab control changes. i use that technique in a number
of forms in my current job, as i'm not partial to opening multiple
independent forms either, and it works quite well.

hth

 

[tina]

well, it sounds like it would pretty complex to work through - at least
mentally - but could be pretty cool when done. one thing to keep in mind
with tabs is that the user can only see one page of a given tab control at
any point in time. one way to keep down the clutter is to put a single
subform control *behind* the tab control, so the subform "shows thru" on all
pages; then assign an appropriate SourceObject to the subform each time the
"current page" of the tab control changes. i use that technique in a number
of forms in my current job, as i'm not partial to opening multiple
independent forms either, and it works quite well.

hth

 

[Jack Leach]

one way to keep down the clutter is to put a single

subform control *behind* the tab control, so the subform "shows thru" on all
pages; then assign an appropriate SourceObject to the subform each time the
"current page" of the tab control changes.

Thanks for the tip Tina. This isn't an active project at the moment, but
I've got a file going on it On the other hand, this might help out
modifying my current setup some (rather than revamping it altogether...)

Just out of curiousity, do you notice any delay when the sourceobject gets
reset? My initial thought here was to use X number of subforms stacked on
top of each other, load them all on the form startup, and .Visible = True and
Requery each time the user initiates a view of that particular form.

I'm curious as to the performance relationship between the two methods. I
don't know if the overhead of always-open but not active forms will weigh out
over not having to set a source object for a subform control on a regular
basis.

No biggie either way, just taking opinions and notes. One of these days
I'll have to make my way over to the UI section at UtterAccess and go through
that...

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[Jack Leach]

one way to keep down the clutter is to put a single

subform control *behind* the tab control, so the subform "shows thru" on all
pages; then assign an appropriate SourceObject to the subform each time the
"current page" of the tab control changes.

Thanks for the tip Tina. This isn't an active project at the moment, but
I've got a file going on it On the other hand, this might help out
modifying my current setup some (rather than revamping it altogether...)

Just out of curiousity, do you notice any delay when the sourceobject gets
reset? My initial thought here was to use X number of subforms stacked on
top of each other, load them all on the form startup, and .Visible = True and
Requery each time the user initiates a view of that particular form.

I'm curious as to the performance relationship between the two methods. I
don't know if the overhead of always-open but not active forms will weigh out
over not having to set a source object for a subform control on a regular
basis.

No biggie either way, just taking opinions and notes. One of these days
I'll have to make my way over to the UI section at UtterAccess and go through
that...

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[tina]

the more bound subform controls on a mainform, the longer it takes to load
the mainform. on the other hand, loading a single subform to an already open
mainform (or loading a single subform when a mainform opens) is normally
very fast - just a simple "one vs many" issue. you might see a lag if you're
loading a complex subform that itself has multiple subforms or other complex
objects on it, otherwise i would expect the process to be transparent to the
user.

i have forms running with half a dozen tabs controlling a single subform,
and no discernable lag in SourceObject change - even though some of the
subforms in turn have two or three bound subforms on them. i have one form
that uses a listbox to control the SourceObject of a subform. i do have a
lag there when loading one particular subform, but that subform is itself a
mainform with nested tab controls and nested subforms - quite the bear to
work with programmatically, but smooth and easy for the user...except for
the loading lag of 3-5 seconds.

another btw: i like tab controls, and use them almost as much as i use
subforms. but i hate the "tabbed" look, and the lack of control of the tabs'
appearance. i usually set a tab control's Style to None, and BackStyle to
Transparent. then i use an option control, usually with toggle buttons, to
control the selection of each tab page, and also loading of subforms as
needed. it's a tiny bit harder to select individual tab pages in Design view
during development, but makes a nice, clean, simple appearance to the user.
if i don't have other controls that need to be displayed/hidden depending on
which subform is loaded, i usually dispense with the tab control altogether,
since the option control is controlling the loading of the subforms anyway.

hth

 

[tina]

the more bound subform controls on a mainform, the longer it takes to load
the mainform. on the other hand, loading a single subform to an already open
mainform (or loading a single subform when a mainform opens) is normally
very fast - just a simple "one vs many" issue. you might see a lag if you're
loading a complex subform that itself has multiple subforms or other complex
objects on it, otherwise i would expect the process to be transparent to the
user.

i have forms running with half a dozen tabs controlling a single subform,
and no discernable lag in SourceObject change - even though some of the
subforms in turn have two or three bound subforms on them. i have one form
that uses a listbox to control the SourceObject of a subform. i do have a
lag there when loading one particular subform, but that subform is itself a
mainform with nested tab controls and nested subforms - quite the bear to
work with programmatically, but smooth and easy for the user...except for
the loading lag of 3-5 seconds.

another btw: i like tab controls, and use them almost as much as i use
subforms. but i hate the "tabbed" look, and the lack of control of the tabs'
appearance. i usually set a tab control's Style to None, and BackStyle to
Transparent. then i use an option control, usually with toggle buttons, to
control the selection of each tab page, and also loading of subforms as
needed. it's a tiny bit harder to select individual tab pages in Design view
during development, but makes a nice, clean, simple appearance to the user.
if i don't have other controls that need to be displayed/hidden depending on
which subform is loaded, i usually dispense with the tab control altogether,
since the option control is controlling the loading of the subforms anyway.

hth

 

[Jack Leach]

hth

This has been a big help, thanks. It's nice to have an idea of what to
expect going into this as well as see how other people handle similar
situations.

I'm in processes of wrapping up "a" version of this now... rather than going
completely to tabs, I was able to take my sidebar setup (image controls in an
up/down navigatable subform on the left of the main) and convert it from
opening seperate detail forms to opening the applicable form as a subform in
the main. It's actually coming along very nicely for a first-of-type project
for me, though I did have to leave it yesterday wondering how to force a save
of the subform before changing the SourceObject
(Me.ctlActiveAnchored.Form.Dirty = False was throwing an error, but it was
late and I was tired... I'll play with it more in the next few days).

I definately like this much better than a bunch of ill-controlled loose forms!

thanks again
--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[Jack Leach]

hth

This has been a big help, thanks. It's nice to have an idea of what to
expect going into this as well as see how other people handle similar
situations.

I'm in processes of wrapping up "a" version of this now... rather than going
completely to tabs, I was able to take my sidebar setup (image controls in an
up/down navigatable subform on the left of the main) and convert it from
opening seperate detail forms to opening the applicable form as a subform in
the main. It's actually coming along very nicely for a first-of-type project
for me, though I did have to leave it yesterday wondering how to force a save
of the subform before changing the SourceObject
(Me.ctlActiveAnchored.Form.Dirty = False was throwing an error, but it was
late and I was tired... I'll play with it more in the next few days).

I definately like this much better than a bunch of ill-controlled loose forms!

thanks again
--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[tina]

you're welcome, Jack. re your save issue: hmm, can you provide details?
when the focus moves from a mainform into a subform, the mainform record
automatically saves; and on moving from the subform back into the mainform,
the subform record automatically saves. so if you dirty the current subform
record, then move back to the mainform (or into another subform on the
mainform) that subform record should save immediately without any
intervention on your part. what behavior are you seeing, and what are the
circumstances?

hth

 

[tina]

you're welcome, Jack. re your save issue: hmm, can you provide details?
when the focus moves from a mainform into a subform, the mainform record
automatically saves; and on moving from the subform back into the mainform,
the subform record automatically saves. so if you dirty the current subform
record, then move back to the mainform (or into another subform on the
mainform) that subform record should save immediately without any
intervention on your part. what behavior are you seeing, and what are the
circumstances?

hth

 

[Jack Leach]

Hi Tina,

This occured to me about an hour after I posted. I had spent the majority
of the previous day doing final testing on a brand new
startup/shutdown/login/out setup (which I finally and happily approved), and
had started with a cheap and dirty base UI setup (just to be doing something
new, really).

The subform.dirty error is where I called it a night, and putting it out of
my mind for the next day, it didn't occur to me until later that night that
it doesn't matter anyway.

I probably won't open this project for a few more days, but I expect no
issues, as I've never heard of any case where a save won't trigger from
parent to child.

Thanks though!

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[Jack Leach]

Hi Tina,

This occured to me about an hour after I posted. I had spent the majority
of the previous day doing final testing on a brand new
startup/shutdown/login/out setup (which I finally and happily approved), and
had started with a cheap and dirty base UI setup (just to be doing something
new, really).

The subform.dirty error is where I called it a night, and putting it out of
my mind for the next day, it didn't occur to me until later that night that
it doesn't matter anyway.

I probably won't open this project for a few more days, but I expect no
issues, as I've never heard of any case where a save won't trigger from
parent to child.

Thanks though!

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[tina]

no problem

Hi Tina,

This occured to me about an hour after I posted. I had spent the majority
of the previous day doing final testing on a brand new
startup/shutdown/login/out setup (which I finally and happily approved), and
had started with a cheap and dirty base UI setup (just to be doing something
new, really).

The subform.dirty error is where I called it a night, and putting it out of
my mind for the next day, it didn't occur to me until later that night that
it doesn't matter anyway.

I probably won't open this project for a few more days, but I expect no
issues, as I've never heard of any case where a save won't trigger from
parent to child.

Thanks though!

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)