Wanted: an interface

[Shawn K. Hall]

Hello Eddie,

If your "frames" are control intensive, you might be better off by
modeling it as an MDI application. You can create an outlook-style bar
at left to select the major group/area which would be represented by
an MDI child form, and if there are subsets of that group you can
refine the presentation more by using a tab control or something to
present the selected frame.

It's also easier for change management, in my experience, if you
separate the objects by nature as best as possible. It's a nightmare
to code for 20 controls on a form, much less a hundred or so. If you
can just move each frame to it's own MDI Child you really take a lot
of the headache out too.

Regards,

Shawn K. Hall
Programmer / Analyst
*Please* post/respond in the newsgroups!


"Eddie Burdak" <eburdak@pilatus-aircraft.com> wrote in message
news:38e83ce2@news.devx.com...
> Hi,
>
> I've got a bit of a dilemma. I'll be making a few apps to be used by
a
> "select" few (poor folks). Anyhow the apps in general will have a
File and
> Edit menu with the usual suspects therein.
>
> But as for the rest of the things they will do they are a smallish
> collection of routines (upto about 30 - roughly). These 30 or so
things that
> can be modeled can be further collected into 5 or 6 sub groups. In
one or
> two cases these may drop to yet another group (sub sub - or what
ever its
> called).
>
> So I can either stick with the normal menu bar or I can use say two
outlook
> style bars - one for the main group and one for the sub group. I've
tried
> this and it looks OK, but I'm still not convinced that this is the
way to
> go.
>
> Also what I do when the user gets there at the end is I tend to drop
all the
> controls (text box's, combos, grids...) into a frame which at run
time is
> sized to fill the rest of the pane - at design time because I have
about 30
> of these **** frames a drag them up when working on them, but then
shrink
> them so I only see the name of the frame and move them away from the
main
> area - eeh is this the best way to go??? A little yucky I've no
doubt - but
> as far as I can determine I think SSTab (OK a really bad example)
tends to
> move the controls of a tab off the form when selecting between tabs
>
> Bottom line I'm still not convinced by the way I'm doing this Has
any one
> got any suggestions/advice???
>
> Thanks
>
> Eddie

[Eddie Burdak]

Hi,

I've got a bit of a dilemma. I'll be making a few apps to be used by a
"select" few (poor folks). Anyhow the apps in general will have a File and
Edit menu with the usual suspects therein.

But as for the rest of the things they will do they are a smallish
collection of routines (upto about 30 - roughly). These 30 or so things that
can be modeled can be further collected into 5 or 6 sub groups. In one or
two cases these may drop to yet another group (sub sub - or what ever its
called).

So I can either stick with the normal menu bar or I can use say two outlook
style bars - one for the main group and one for the sub group. I've tried
this and it looks OK, but I'm still not convinced that this is the way to
go.

Also what I do when the user gets there at the end is I tend to drop all the
controls (text box's, combos, grids...) into a frame which at run time is
sized to fill the rest of the pane - at design time because I have about 30
of these **** frames a drag them up when working on them, but then shrink
them so I only see the name of the frame and move them away from the main
area - eeh is this the best way to go??? A little yucky I've no doubt - but
as far as I can determine I think SSTab (OK a really bad example) tends to
move the controls of a tab off the form when selecting between tabs

Bottom line I'm still not convinced by the way I'm doing this Has any one
got any suggestions/advice???

Thanks

Eddie

[Phil Weber]

> If your "frames" are control intensive, you might be
> better off by modeling it as an MDI application.

Shawn: With all due respect, I disagree. MDI should be used for manipulating
multiple instances of a single type of document (e.g., Word docs, Excel
workbooks, etc.). Using MDI child forms as dialog boxes is a bad idea (can
you think of any app you enjoy using that does this?).
---
Phil Weber

[Phil Weber]

> So I can either stick with the normal menu bar or I can use
> say two Outlook-style bars - one for the main group and one
> for the sub group. I've tried this and it looks OK, but I'm still
> not convinced that this is the way to go.

Eddie: I don't think you should use two Outlook-style listbars. If you want
to combine functions into groups and subgroups, you might use a listbar for
the groups and a tab control for the subgroups. Or, you could use a TreeView
along the left-hand side to show the function hierarchy.

As to the controls that appear on the right-hand side when the user selects
a function, I'd suggest developing each 'page' as a UserControl (I assume
you're using VB; a similar technique may be applied in other languages). The
solves several problems:

1. It allows you to develop the pages individually, without
their stepping on each other at design time;

2. It allows you to upgrade the pages, or even add new
ones, without having to recompile and distribute your
entire application;

3. It allows you to load only the active page in memory,
rather than loading the controls for all 30 pages when
the app starts and having them consume resources for
as long as it's running.

---
Phil Weber

[Eddie Burdak]

Shawn,

thanks for the response

> If your "frames" are control intensive, you might be better off by
modeling it as an MDI application.

Hmm, a good idea - better then 30 odd frames littering everywhere. I tended
to stay away from MDI forms. But essentially that is what I'm doing here.

>
.............................................................................
.....................If you
> can just move each frame to it's own MDI Child you really take a lot
> of the headache out too.

A valid point.

Thanks

Eddie

[Shawn K. Hall]

Hello Phil,

It really depends on how it's designed. If you limit your use of MDI
to simply "notepad-on-steroids" type documents where each item
contained is simply an instance of the same form, you are missing the
boat with it. MDI lets you create child forms that are more than just
notepad documents, they can be complete interface elements, as
powerful as any other form, with dynamic menus, interactively built
into the MDI forms menus, which - as far as I know - a usercontrol
cannot do easily. Setting the properties properly on the MDI child
will enable it to seamlessly integrate with the MDIForm, so that the
two together cannot be distinguished from a single non-MDI form. I
agree that using usercontrols is another solution, but to simply
overlook MDI child forms as a possible solution simply because you are
not accustomed to seeing them in use for other than "notepad on
steroids" apps is a poor design decision.

Out of curiosity, how would you implement a data driven application
that interfaced into over twenty major tables (30+ fields each) - each
a different subset of data (eg; people, equipment, locations, finance,
purchase orders, suppliers, personnel time), but requiring a
consistent and manageable UI, table dependant menus (eg; "add user",
"update lease information", "personnel action") and latent
reference-bound field-level validation?

I've written several apps that do this; my current project is *very*
large scale, and I simply can't imagine accomplishing it with a single
form, even with usercontrols at any point in time there would be some
800+ controls in memory (through the usercontrols) if it were allowed
to happen (unfortunately, that's not an exaggeration). An MDI
environment allows you to load the form as necessary and not load a
form (and it's children) if they will not be used.

Maybe it's just because I'm writing it, but I really enjoy using it
too. <g>

Respectfully,

Shawn K. Hall
Programmer / Analyst
*Please* post/respond in the newsgroups!


"Phil Weber" <pweber@teleport.com> wrote in message
news:38e86452$1@news.devx.com...
> > If your "frames" are control intensive, you might be
> > better off by modeling it as an MDI application.
>
> Shawn: With all due respect, I disagree. MDI should be used for
manipulating
> multiple instances of a single type of document (e.g., Word docs,
Excel
> workbooks, etc.). Using MDI child forms as dialog boxes is a bad
idea (can
> you think of any app you enjoy using that does this?).
> ---
> Phil Weber

[Eddie Burdak]

Phil,

thanks for your response.

> Eddie: I don't think you should use two Outlook-style listbars.

Hmm, pity - I quite liked the effect, but I'm not totally sold on it - which
is why I'm asking.

> Or, you could use a TreeView along the left-hand side to show the function
hierarchy.

Yes, TreeView is a definitie possibility. I just didnt think it was good
usage of a TreeView as I would have thought TreeView is when you have
(possibly) quite a few options. I just feel that the number of options
didn't warrant a TreeView.

> As to the controls that appear on the right-hand side when the user
selects
> a function, I'd suggest developing each 'page' as a UserControl (I assume
> you're using VB; a similar technique may be applied in other languages).

1) Yes, sorry, I'm using VB6

2) Could you expand a little on "UserControl" and 'page'. If a page is not
another form how would you see a way of constructing it? At the moment I was
thinking more along the lines of a single form and just enabling the
appropiate frame - but it does make it a little difficult to keep tabs on
the options. I dont think that is what you mean. How would you do a page -
you make it sound almost like a standalone exe.

> 2. It allows you to upgrade the pages, or even add new
> ones, without having to recompile and distribute your
> entire application;

Now this idea I do like the sound of - but I have no idea on how to
proceed - could you please clarify (was there an example or something in
VBPJ I could refer too)

> 3. It allows you to load only the active page in memory,
> rather than loading the controls for all 30 pages when
> the app starts and having them consume resources for
> as long as it's running.

I'm afraid I simply dont know enough about VB. If, for example, I have an
MDI application but only call, say, 1/3 of the available forms - are you
saying that all the forms are in memory - even if I'm using just some of
them?

Thanks

Eddie

[Eddie Burdak]

Phil,

I've done a little hunting

> As to the controls that appear on the right-hand side when the user
selects
> a function, I'd suggest developing each 'page' as a UserControl (I assume
> you're using VB; a similar technique may be applied in other languages).
The
> solves several problems:

I've found "Make your Apps easier to navigate" - Mar 98 - Tim Greenfield

but this method is not explained very clearly and there is no example code
to play with.

Or where you thinking of something else by any chance?

Thanks

Eddie

[Adelle Hartley]

Thanks Shawn.
I have a similar problem to Eddie's, and I don't know why I didn't
think of the MDI solution myself - especially since I am already using an
MDI
form with a maximised child window as the switchboard.

Our company has developed quite a few apps using a tree-view
to navigate but then making individual frames appear/disappear
as different nodes are selected. I can see how using child windows
would be so much better - whatever control is used for navigation.

BTW, in my last VB project, I created six dialog windows which each had
a tab-control with (the same) six tabs on them. I created the illusion of
all six
forms being the one dialog by making them appear/disappear as each
tab was selected.

Somewhat hokey compared to the MDI solution, but it did work.

Adelle.

Shawn K. Hall <shawnkhall@iname.com> wrote in message
news:38e84849$1@news.devx.com...
> Hello Eddie,
>
> If your "frames" are control intensive, you might be better off by
> modeling it as an MDI application. You can create an outlook-style bar
> at left to select the major group/area which would be represented by
> an MDI child form, and if there are subsets of that group you can
> refine the presentation more by using a tab control or something to
> present the selected frame.
>
> It's also easier for change management, in my experience, if you
> separate the objects by nature as best as possible. It's a nightmare
> to code for 20 controls on a form, much less a hundred or so. If you
> can just move each frame to it's own MDI Child you really take a lot
> of the headache out too.
>
> Regards,
>
> Shawn K. Hall
> Programmer / Analyst
> *Please* post/respond in the newsgroups!
>
>

[Shawn K. Hall]

You're welcome Adelle,

Something that I'm using with my current app is VideoSoft's vsElastic
control - it does some really cool things for an MDI app. I have to
have an "area listing" like Outlook's GUI - and it makes it all well
worth whatever time it would have taken me to code form resizes and
control adjustments.

You might have a look at it if you do anything like the one you
describe again,

Shawn K. Hall
Programmer / Analyst
*Please* post/respond in the newsgroups!
http://i.am/shawnkhall


"Adelle Hartley" <adelle@verdant.com.au> wrote in message
news:39168531@news.devx.com...
> Thanks Shawn.
> I have a similar problem to Eddie's, and I don't know why I didn't
> think of the MDI solution myself - especially since I am already
using an
> MDI
> form with a maximised child window as the switchboard.
>
> Our company has developed quite a few apps using a tree-view
> to navigate but then making individual frames appear/disappear
> as different nodes are selected. I can see how using child windows
> would be so much better - whatever control is used for navigation.
>
> BTW, in my last VB project, I created six dialog windows which each
had
> a tab-control with (the same) six tabs on them. I created the
illusion of
> all six
> forms being the one dialog by making them appear/disappear as each
> tab was selected.
>
> Somewhat hokey compared to the MDI solution, but it did work.
>
> Adelle.
>
> Shawn K. Hall <shawnkhall@iname.com> wrote in message
> news:38e84849$1@news.devx.com...
> > Hello Eddie,
> >
> > If your "frames" are control intensive, you might be better off by
> > modeling it as an MDI application. You can create an outlook-style
bar
> > at left to select the major group/area which would be represented
by
> > an MDI child form, and if there are subsets of that group you can
> > refine the presentation more by using a tab control or something
to
> > present the selected frame.
> >
> > It's also easier for change management, in my experience, if you
> > separate the objects by nature as best as possible. It's a
nightmare
> > to code for 20 controls on a form, much less a hundred or so. If
you
> > can just move each frame to it's own MDI Child you really take a
lot
> > of the headache out too.
> >
> > Regards,
> >
> > Shawn K. Hall
> > Programmer / Analyst
> > *Please* post/respond in the newsgroups!
> >
> >
>
>
>

[Kevin Downs]

Dynamic MDI Forms-A New Approach by Dan Appleman
VBPJ, March 1999

Unfortunately this is in the premier club area.....

--
Regards,
Kevin

"Eddie Burdak" <eburdak@pilatus-aircraft.com> wrote in message
news:38e8981b$1@news.devx.com...

> Now this idea I do like the sound of - but I have no idea on how to
> proceed - could you please clarify (was there an example or something in
> VBPJ I could refer too)
>