Is MDI a sensible choice for this app? If not, what is?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi all,

I am trying to develop an application which is replacing an obselete
application running in DOS on old hardware. We are replacing it with a system
running Windows XP, and my new software which will be written in Visual C++
..Net.

The old system has a number of screens, each of which can be accessed using
one of the Function keys (eg. F6 goes to the System Status screen). Each of
these screens has some elements which are the same. For example, each screen
has two listboxes at the bottom for Error Messages and Alarm Messages, each
screen has a similar header bar etc.

The question really is, how do you suggest I implement this? From my
experience (mainly in VB6, but also a quite a bit of experience now in .Net
languages) I thought of using a Multiple Document Interface (MDI) paradigm. I
could have one 'parent' form which had the list views etc on them, and then
each screen could be a child form. This sounds perfect in theory, but there
are quite a number of problems. These include the difficulty of communicating
from parent to child (it seems that you have to cast it to the type of the
child form, which is difficult if you're not sure what form is displayed at
the current time!). Also, these child forms should not be able to be moved
around, resized, or minimised, but even if I set the child form to be
maximised, and turn off all the options for the control box buttons they
still seem to appear! The only way I have managed to get it to look how I
want is to set the child form to have no border, and to manually size it to
*just* the right size so that it fits inside the parent form perfectly. Of
course if the size of the parent form changes then these pixel sizes will
need to be changed.

As I've said, overall I seem to have had quite a few problems with the MDI -
the main one being the communication between parent and child (and vice
versa) and I'm wondering if I should still keep trying to solve these
problems (if anyone has any solutions I'd love to hear them) or if there is a
better way to do it?

Thanks,

Robin
 
Hi all,

I am trying to develop an application which is replacing an obselete
application running in DOS on old hardware. We are replacing it with a system
running Windows XP, and my new software which will be written in Visual C++
.Net.

The old system has a number of screens, each of which can be accessed using
one of the Function keys (eg. F6 goes to the System Status screen). Each of
these screens has some elements which are the same. For example, each screen
has two listboxes at the bottom for Error Messages and Alarm Messages, each
screen has a similar header bar etc.

The question really is, how do you suggest I implement this? From my
experience (mainly in VB6, but also a quite a bit of experience now in .Net
languages) I thought of using a Multiple Document Interface (MDI) paradigm. I
could have one 'parent' form which had the list views etc on them, and then
each screen could be a child form. This sounds perfect in theory, but there
are quite a number of problems. These include the difficulty of communicating
from parent to child (it seems that you have to cast it to the type of the
child form, which is difficult if you're not sure what form is displayed at
the current time!). Also, these child forms should not be able to be moved
around, resized, or minimised, but even if I set the child form to be
maximised, and turn off all the options for the control box buttons they
still seem to appear! The only way I have managed to get it to look how I
want is to set the child form to have no border, and to manually size it to
*just* the right size so that it fits inside the parent form perfectly. Of
course if the size of the parent form changes then these pixel sizes will
need to be changed.

As I've said, overall I seem to have had quite a few problems with the MDI -
the main one being the communication between parent and child (and vice
versa) and I'm wondering if I should still keep trying to solve these
problems (if anyone has any solutions I'd love to hear them) or if there is a
better way to do it?

Thanks,

Robin
Click to expand...

If an application is obsolete, why are you rewriting it?

If you can only have one form active at a time, then that would
indicate that the application is not a good candidate for MDI. Purely
on the basis that you won't be working with multiple documents (or
forms) at once.

If you have a lot of commonality between forms make your own base form
(derived from a standard form) which could include the header bar, two
list boxes, etc. Then derive your actual forms from that.

Porting an application to a different environment can be a complicated
process.
You need to understand why you are porting.
Are you looking to change functionality or just the platform that the
application runs on?
You are not porting just for the sake of having the program written in
another language, are you?
What constraints is the business putting on the port? (time,
resources, training requirements, etc.)
How big / complex is the application? This can have a big impact on
design.
A windows form application can be very different to a DOS one. How
different is the new application allowed to be from the old one? What
windows controls are you allowed to introduce?
How controlled is your user environment? Having forms that can't be
resized can have a lot of implications for compatibility on different
machines and if you have large forms this can cause problems on a
small display.


In the past I have worked on two projects that involved porting from
DOS.
One one we created a dummy interface so that even though it was a
windows forms app it looked like DOS. (It was all green text on a
black background.) We did it this way as the purpose of the port was
to move from terminal based machines to Windows desktops. There would
be no time to train hundreds of users in a new system. Users had to
be able to log out of the old system one day and log into the new one
the next without any help or any delay in productivity. (The cost of
any delay could be calculated down to the second, so having people not
know what they were doing could be very costly.)

On the other we redesigned the entire app in view of the resources
available. Not only did the new application look completely different
but it also required that the user interact with it in different ways.
(and not just from a keyboard vs mouse driven standpoint.)
This process took longer but created a much better product. One that
was quicker and easier for people to both learn and use.


I hope this provides a few pointers/ideas.

Matt.
 
Back
Top