Strategy to Refresh Multiple Forms Simultaneously

[Jeff]

I plan to write a Windows Forms MDI application for a medical office. Users
must be able to select a patient and view related information on multiple
forms; with1-4 forms opened at the same time for the same patient; each form
showing a different type of patient-related information.

After viewing information for one patient (say on 3 forms opened
simultaneously) , users want the ability to select another patient. Upon
selection of another patient all currently opened forms should show their
respective data for the new patient. Also, when a form is opened, it must
show its data for the currently selected patient. Each form will present
data that is editable.

I tentatively plan to implement the "patient search" feature in a modal
dialog.

My question is for a high-level strategy for managing this UI (e.g.,
updating any/all currently opened forms with data for the newly selected
patient, etc). What I would appreciate are suggestions for the various
high-level building blocks that you think would work well for this scenario;
e.g,. the logical layers and/or classes to create and the role each would
play.

FWIW: The data will reside in a SQL Server db. The system will have
approximately 150 users all on a high-speed LAN, with no need for remote
access.

Thank you for your time and consideration!

[Mark R. Dawson]

Hi Jeff,
you probably want to start looking into the "Model View Controller"
pattern for your interface design. This design allows you to seperate the
data you want to view from the view of the data. You can then have multiple
views looking at the same data and updating syncronously.

Also Microsoft have their own take on this approach called the "User
Interface Process Application Block" which is similar to the MVC.

Mark.

"Jeff" wrote:

I plan to write a Windows Forms MDI application for a medical office. Users
must be able to select a patient and view related information on multiple
forms; with1-4 forms opened at the same time for the same patient; each form
showing a different type of patient-related information.

After viewing information for one patient (say on 3 forms opened
simultaneously) , users want the ability to select another patient. Upon
selection of another patient all currently opened forms should show their
respective data for the new patient. Also, when a form is opened, it must
show its data for the currently selected patient. Each form will present
data that is editable.

I tentatively plan to implement the "patient search" feature in a modal
dialog.

My question is for a high-level strategy for managing this UI (e.g.,
updating any/all currently opened forms with data for the newly selected
patient, etc). What I would appreciate are suggestions for the various
high-level building blocks that you think would work well for this scenario;
e.g,. the logical layers and/or classes to create and the role each would
play.

FWIW: The data will reside in a SQL Server db. The system will have
approximately 150 users all on a high-speed LAN, with no need for remote
access.

Thank you for your time and consideration!

[Bruce Wood]

You want to look into the Model-View-Presenter pattern. I don't use it
exactly as written. I'll give you an outline of what I'm doing, but
I'll talk in terms of a "Patient" group of objects so it's more
applicable to what you're doing.

In my system, I would have the following classes:

Patient
PatientCollecti on
PatientData
PatientValidato r

and then all of my forms. The uses of these classes are as follows.

Patient represents a validly constructed patient, either one from the
database, or a newly constructed or edited one ready to be written back
to the database. Patient always contains self-consistent, valid
information, and provides operations for getting information about the
patient, etc.

PatientCollecti on is a collection of patients, along with any useful
methods for searching / fetching / etc. collections of patients.

PatientData is the data layer that mediates between the SQL
representation and the Patient object. How you want to do that is up to
you. (A Patient, for example, could internally store its information as
a DataRow, or as individual private members. It's up to you.)

PatientValidato r is needed only if you're modifying patient
information. Whereas a Patient always contains valid patient
information, a PatientValidato r acts a the Model portion of the UI, so
it's capable of holding partially-modified patient information in a
(temporarily) "bad" state. It knows how to check whether the patient
information it's holding is OK, and knows how to issue helpful error
messages if some patient information is invalid. PatientValidato r has a
property or method that the UI can call to check if the patient info is
OK, and another to build a new Patient object if the patient info is
OK.

Now here's the cool part. PatientValidato r exposes most of the
properties that a Patient does, but each property has a ...Changed
event associated with it. So, for example, you might have a FirstName
property, which would have a corresponding FirstNameChange d event.
Every public property has a corresponding Changed event.

Now, each form you write to display patient information doesn't
actually store any patient information. All it does is subscribe to the
PatientValidato r's ...Changed events. When a ...Changed event is
raised, the form reads the new information from the validator and
displays it on the screen. When the user changes something in a
control, the form sets the corresponding property in the validator.

To this I added ...Relevant and ...Changeable properties and
corresponding ...RelevantChan ged and ...ChangeableCh anged events. This
allows the validator to tell the display when particular fields should
appear / disappear, and when they should be enabled / disabled.

The beauty of this (which is sort of a bastardized form of MVP) is that
all of the business logic about how fields interact is in the
PatientValidato r, the model. The forms are just views into that
information that react to changes in the model and make changes to the
model.

In fact, if you do things this way, _as soon as_ the user modifies
something on one form, the other forms will change what they display to
stay in synch.

Of course, if you're not editing patient information, just displaying
it, then you can cut down the complexity quite a bit, but the same
approach applies: one model object that raises events when things
change, and every form is just a dumb view into that data.

How you handle the data layer beneath this is really up to you and
doesn't impact the UI design at all.

[Jeff]

Oh, that's good! very good! I can see it in action now.

Thank you.
"Bruce Wood" <br*******@cana da.com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. .

You want to look into the Model-View-Presenter pattern. I don't use it
exactly as written. I'll give you an outline of what I'm doing, but
I'll talk in terms of a "Patient" group of objects so it's more
applicable to what you're doing.

In my system, I would have the following classes:

Patient
PatientCollecti on
PatientData
PatientValidato r

and then all of my forms. The uses of these classes are as follows.

Patient represents a validly constructed patient, either one from the
database, or a newly constructed or edited one ready to be written back
to the database. Patient always contains self-consistent, valid
information, and provides operations for getting information about the
patient, etc.

PatientCollecti on is a collection of patients, along with any useful
methods for searching / fetching / etc. collections of patients.

PatientData is the data layer that mediates between the SQL
representation and the Patient object. How you want to do that is up to
you. (A Patient, for example, could internally store its information as
a DataRow, or as individual private members. It's up to you.)

PatientValidato r is needed only if you're modifying patient
information. Whereas a Patient always contains valid patient
information, a PatientValidato r acts a the Model portion of the UI, so
it's capable of holding partially-modified patient information in a
(temporarily) "bad" state. It knows how to check whether the patient
information it's holding is OK, and knows how to issue helpful error
messages if some patient information is invalid. PatientValidato r has a
property or method that the UI can call to check if the patient info is
OK, and another to build a new Patient object if the patient info is
OK.

Now here's the cool part. PatientValidato r exposes most of the
properties that a Patient does, but each property has a ...Changed
event associated with it. So, for example, you might have a FirstName
property, which would have a corresponding FirstNameChange d event.
Every public property has a corresponding Changed event.

Now, each form you write to display patient information doesn't
actually store any patient information. All it does is subscribe to the
PatientValidato r's ...Changed events. When a ...Changed event is
raised, the form reads the new information from the validator and
displays it on the screen. When the user changes something in a
control, the form sets the corresponding property in the validator.

To this I added ...Relevant and ...Changeable properties and
corresponding ...RelevantChan ged and ...ChangeableCh anged events. This
allows the validator to tell the display when particular fields should
appear / disappear, and when they should be enabled / disabled.

The beauty of this (which is sort of a bastardized form of MVP) is that
all of the business logic about how fields interact is in the
PatientValidato r, the model. The forms are just views into that
information that react to changes in the model and make changes to the
model.

In fact, if you do things this way, _as soon as_ the user modifies
something on one form, the other forms will change what they display to
stay in synch.

Of course, if you're not editing patient information, just displaying
it, then you can cut down the complexity quite a bit, but the same
approach applies: one model object that raises events when things
change, and every form is just a dumb view into that data.

How you handle the data layer beneath this is really up to you and
doesn't impact the UI design at all.

[Nick Hounsome]

"Jeff" <[e-mail]> wrote in message
news:Ov******** ******@TK2MSFTN GP15.phx.gbl...

I plan to write a Windows Forms MDI application for a medical office. Users
must be able to select a patient and view related information on multiple
forms; with1-4 forms opened at the same time for the same patient; each
form showing a different type of patient-related information.

After viewing information for one patient (say on 3 forms opened
simultaneously) , users want the ability to select another patient. Upon
selection of another patient all currently opened forms should show their
respective data for the new patient. Also, when a form is opened, it must
show its data for the currently selected patient. Each form will present
data that is editable.

I tentatively plan to implement the "patient search" feature in a modal
dialog.

My question is for a high-level strategy for managing this UI (e.g.,
updating any/all currently opened forms with data for the newly selected
patient, etc). What I would appreciate are suggestions for the various
high-level building blocks that you think would work well for this
scenario; e.g,. the logical layers and/or classes to create and the role
each would play.

FWIW: The data will reside in a SQL Server db. The system will have
approximately 150 users all on a high-speed LAN, with no need for remote
access.

Thank you for your time and consideration!

You could just use a strongly typed DataSet since you will probably be using
one to get the data anyway.

Of course you run into the problem with the designer where it wants to use a
new instance of the dataset for each form but it is easy to write a method
to "copy" all of the delegates attached to dataset in the design onto a
similarly typed dataset supplied as a property.

This will give you updates,undo,li sts and easy database integration.

It is much simpler and easier to implement than the other suggestion with
Patient etc as explicit classes however it really depends on how big the
application is - the bigger and more complicated it gets the more you should
tend towards explicit custom modelling

[rossum]

On Wed, 25 Jan 2006 20:42:41 -0800, "Jeff" <[e-mail]> wrote:

I plan to write a Windows Forms MDI application for a medical office. Users
must be able to select a patient and view related information on multiple
forms; with1-4 forms opened at the same time for the same patient; each form
showing a different type of patient-related information.

After viewing information for one patient (say on 3 forms opened
simultaneously ), users want the ability to select another patient. Upon
selection of another patient all currently opened forms should show their
respective data for the new patient. Also, when a form is opened, it must
show its data for the currently selected patient. Each form will present
data that is editable.

I tentatively plan to implement the "patient search" feature in a modal
dialog.

My question is for a high-level strategy for managing this UI (e.g.,
updating any/all currently opened forms with data for the newly selected
patient, etc). What I would appreciate are suggestions for the various
high-level building blocks that you think would work well for this scenario;
e.g,. the logical layers and/or classes to create and the role each would
play.

FWIW: The data will reside in a SQL Server db. The system will have
approximatel y 150 users all on a high-speed LAN, with no need for remote
access.

Thank you for your time and consideration!

A thought. Would it simplify the problem if you used tabbed forms
rather than MDI? That way only one form is visible at a time and each
form/tab can be updated as it is selected. Obviously your users would
have to be happy with this. You will probably need to put more data
on each page as they will not be able to have different pages visible
at the same time.

rossum

--

The ultimate truth is that there is no ultimate truth

[placidpundit]

Other suggestions have been good but I have something to add here: use
a public static instance of whatever object you're storing data in. I
am doing this with an application similar to yours and have found it to
work well. I just declare a public static DataSet in my main form and
instantiate it immediately in the constructor. Then, I refer to it
everywhere as MainForm.dataMo del. Other forms that use it are signed
up to be notified via an event when it changes.

[Bruce Wood]

I do something similar: I use a Singleton here. I started with a static
but then found that I needed to take advantage of inheritance (I had a
data handler for each type of business object, and they had
functionality in common). Of course, static and inheritance don't mix,
so I cooked up a Singleton solution, instead, which is still going
strong.