"Mike MacSween" <mi***********************@btinternet.com> wrote in
news:40***********************@news.aaisp.net.uk:
It's a form, with (so far) 4 tab pages on it, each of which holds
2/3/4 subforms.
(I like tabbed forms by the way - do we all?)
Yes, I'm a tabbed form addict. My users taught me to be, as they
hate popup forms, in general, because it's too easy to get lost.
(a fascinating article on UI design errors:
http://www.catb.org/~esr/writings/cups-horror.html
I recommend that everyone read this and the followup referred to at
the end; it's not about tabbed interfaces, but it makes a number of
points that are pretty important)
Basically the subforms are different ways of looking at the data.
It's the orchestral management thing still.
So tab 1 looks at each musician, the events they're booked onto,
which jobs they're doing etc.
tab 2 looks at each job, who's doing it at which event etc.
To preserve state between tabs I've set up a few form level
variables, so that when you're on musician A on one subform when
you switch to another tab you'll be on musician A there too.
Hopefully.
Is form level variables the usual way to accomplish this? If there
is a 'usual' way.
Well, shouldn't this be data-driven?
The usual design of a parent form/subform is that the subforms are
linked to the record displayed in the parent form. That would be a
very easy way to coordinate multiple subforms.
If, on the other hand, your parent form is unbound and displays a
number of subforms that are not all children of the same parent, you
could create a control that does display the common information and
use that for your link.
That is, if you're moving between two tabs that both display
information about the same person, there ought to be a header in
common to those two tabs that displays which person the child data
is about, and also allows you to navigate to a different person.
One way to accomplish this would be to have the "header" portion of
the form be a tab control with no tabs displayed. You'd have
sufficient tabs on it to display as many different headers as you
needed, with navigation for those headers, and the tab shown on the
header would be driven in the OnChange event of the tab.
I can see possible problems with that with certain kinds of design,
but you get the idea, maybe. The principle is that there should be a
header that is shared between tabs that display the same kind of
information.
And if you need different headers, you might consider breaking the
whole thing down into separate forms. While I avoid popups so users
don't have to navigate between different forms all the time, I do
think you need to keep distinct entities separated from each other.
--
David W. Fenton
http://www.bway.net/~dfenton
dfenton at bway dot net
http://www.bway.net/~dfassoc 
