Calling a method in one MDI child from another MDI child

  • Thread starter Thread starter Earl
  • Start date Start date
E

Earl

I need to call a method on an owned child form, and am wondering if the best
way of doing this is to capture the Closing event of the form that passes
control back to the form where I have the method. The structure is like so:

frmMain (MDI, runs on app start) calls
frmB (MDI child), which in turn calls
frmC (MDI child), which in turn calls
frmD (MDI child).

frmMain and frmB remain open while frmC and frmD are shown.

frmC and frmD each close as they finish processing.

Once the user makes selections, frmD then needs to pass control back to frmB
(right before closing) and fire a method that populates certain controls on
frmB. So my first thought is to add a handler to frmB to capture the Closing
event of frmD, and use that handler to call the method to populate the
controls on frmB. Is there a better way, either easier, more
straightforward, or more efficient?
 
Earl,

Why don't you use delegates? Pass a delegate object at the time you
instantiate the second child form.

Rgs,

Robson Siqueira
 
Earl,

In my opinion rather than FormD notifying FormB of happening of an
event, FormB should be retrieving this information from FormD (or
through FormC per your example). That would make FormD independent and
agnostic about notifying other objects (FormB in this case). To
complicate things in MDI you can have multiple instances of FormB's,
FormC's and FormD's at any given point.
What we need to figure out is a way to pass information between these
forms. Considering these, I would set the behavior of FormD (and FormC
*may be* per your example) to modal instead of mdichild. That way FormB
has reference to FormC->/FormD through which it would retrieve the
necessary information the code would look something like this:

FormD newMdiChild = new FormD();
if (newMdiChild.ShowDialog(this) == DialogResult.OK)
{
this.SomeValue = newMdiChild.SomeProperty;
//retreive other values ..so on
}


Raaj.
 
Good food for thought Raaj.

I could almost move the controls and logic of FormB back to the main form --
if I did not want to keep it as an independent entity. The point being, I
only need one copy of it ever in the app. And the design of the main form is
so clean, it merely controls the app, does the intial checks, hosts the
menustrip, etc.

FormC on the other hand could indeed be called multiple times. But it too is
only needed once for every iteration of FormB (FormC gets spawned by a
button click on FormB only). And the flow of data and control is one-way: if
a certain search condition is met, either FormD gets shown or we fall back
into FormB.

FormD can only get created by FormC. Seems a remote possibility, but not
impossible that it could be created more than once (altho I can prevent
that).

I'm not sure how you are envisioning FormB retrieving information from
FormD. May be a matter of semantics, I view it as FormD passing the
information back to FormB.
 
Good food for thought Raaj.
I could almost move the controls and logic of FormB back to the main form --
if I did not want to keep it as an independent entity. The point being, I
only need one copy of it ever in the app. And the design of the main form is
so clean, it merely controls the app, does the intial checks, hosts the
menustrip, etc.
Click to expand...
No not really you don't have to change anything in MainForm or FormB,
they are good. There is nothing wrong with FormB in my perspective
either. I was referring to FormD which will be dependent if it
references anything in FormB (Refer to my example below for what I
mean)
FormC on the other hand could indeed be called multiple times. But it too is
only needed once for every iteration of FormB (FormC gets spawned by a
button click on FormB only). And the flow of data and control is one-way: if
a certain search condition is met, either FormD gets shown or we fall back
into FormB.
Click to expand...

I agree
FormD can only get created by FormC. Seems a remote possibility, but not
impossible that it could be created more than once (altho I can prevent
that).
Click to expand...
It appears we both are on the same page here

I view it as FormD passing the information back to FormB.
Click to expand...
I somewhat disagree
I'm not sure how you are envisioning FormB retrieving information from
FormD.
Click to expand...
The following should explain what I visualize when I say FormB should
retrieve information from FormD

To simplify, let's consider a realistic example and for sake of
example assume the hierarchy is as follows. Please note that the code
below is not compiled and it is for illustration only (typewritten in
notepad)

UI Hierarchy
=========
MainForm

|
FormOrder (MdiChild)(FormB per our example) (Populates
IPoOrder)
|

FormOrderItems (Modal Form) (FormC per our
example) (Populates IPoItemCol)
|

FormOrderLineItem (Modal Form) (FormD per
our example) (Populates IPoItem)


In the below code FormOrder creates an instance of the FormOrderItems
and ultimately gets an instance of order collection. In addition,
FormOrder of course will have reference to other controls may be to
Order Header related information (IPoOrder)

//Code Snippet in FormOrder
private void buttonEnterLineItems_Click(object sender, EventArgs e)
{
EnterOrderLines();
}

private void EnterOrderLines()
{
FormOrderItems objFormOrderItems = new FormOrderItems();
if (objFormOrderItems.ShowDialog(this) == DialogResult.OK)
{
//if all is *well* objFormOrderItems would retrieve an instance
of IPoItemCol
this.PoOrder.PoItemCol = objFormOrderItems.GetOrderCollections;
if ((this.PoOrder.PoItemCol == null) ||
(this.PoOrder.PoItemCol.Count <= 0))
throw new EOrderException(....) //exception to business
rules...
}
}


The FormOrderItems creates (or reuses) an instance of FormOrderLineItem
for every new item in the order. FormOrderItems is responsible for
populating the Orderlines Collection instance with instances of
orderline.

//Code in FormOrderItems
private void buttonNewItem_Click(object sender, EventArgs e)
{
AddLineItem();
}


private void AddLineItem()
{
FormOrderLineItem objFormOrderLineItem = new FormOrderLineItem();
if objFormOrderLineItem.ShowDialog(this) == DialogResult.OK)
{
//if all is well objFormOrderLineItem would return a valid IPoItem
IPoItem PoItem = objFormOrderLineItem.GetLineItem;
If (PoItem == null)
throw new EOrderLineException(...); //Exception
this.PoItemCol.Add(POItem);

}

}

Apparently notice that OrderLines collection is passed to the
FormOrders. This is what I originally meant when I said the FormB
should retrieve details from FormD.

Also, When I say FormB should retrieve details that also correlates to
this statement "Given its position (and logical functionality) in the
hierarchy FormD should have no idea who its users are and what there
business are. On the other end all that users (FormB or FormC) of FormD
know in a nut shell is given a set of inputs FormD throws a set of
predefined output or exception to business rules"

This is how I view it:

1. FormOrderLine (FormD) Item should not know anything about
FormOrderLines (FormC) or FormOrder (FormB)

2. If FormOrderLine has reference to any of the attributes or events in
the FormOrderLines or FormOrder they are interwoven. Then this isn't
reusable either, think of a generic lookup collection such as customer
lookup. If the Customerlookup subscribes to events or methods specific
to order form (Orders Module) then it is an initiation to coupling. The
customerLookup now is no more a blackbox component, nor can we reuse it
in other modules as efficiently. Given its functionality, let us say we
have to (or forced to) resuse the CustomerLookup in an Invoice Form
(Invoicing Module) we will be tempted to subscribe to events or
delegates in Invoice form aswell in the advert of *reusability*. The
Customerlookup would end up as an interconnected mass of spaghetti over
a couple of iterations.

I hope I have articulated my thoughts in line to your question.

Raaj.
 
Thanks for the explanation Raaj. The form names being a little hard to
follow, I did grasp the hierarchy, and most importantly that you recommend
using modal forms for all sub-forms below the order form (or frmB in my
example). I also saw the use of the collections, although I am probably
going to organize the hierarchy slightly different in that I'm going to
simply expose properties on frmD to use on frmB. Once control is returned to
frmB, I'll call a method to uses the properties on frmD before Disposing of
frmC and frmD.
 
Back
Top