473,320 Members | 1,863 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Calling a method in one MDI child from another MDI child

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?
Dec 20 '06 #1
5 2221
Earl,

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

Rgs,

Robson Siqueira

"Earl" <br******@newsgroups.nospamwrote in message
news:uI**************@TK2MSFTNGP04.phx.gbl...
>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?

Dec 20 '06 #2
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.

Earl wrote:
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?
Dec 21 '06 #3
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.


"Raaj" <ra***********@yahoo.comwrote in message
news:11**********************@80g2000cwy.googlegro ups.com...
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.

Earl wrote:
>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?

Dec 21 '06 #4
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.
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.
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).
It appears we both are on the same page here

I view it as FormD passing the information back to FormB.
I somewhat disagree
I'm not sure how you are envisioning FormB retrieving information from
FormD.
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.

Earl wrote:
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.


"Raaj" <ra***********@yahoo.comwrote in message
news:11**********************@80g2000cwy.googlegro ups.com...
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.

Earl wrote:
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?
Dec 21 '06 #5
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.

"Raaj" <ra***********@yahoo.comwrote in message
news:11**********************@a3g2000cwd.googlegro ups.com...
>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.
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.

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).
It appears we both are on the same page here

>I view it as FormD passing the information back to FormB.
I somewhat disagree
>I'm not sure how you are envisioning FormB retrieving information from
FormD.
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.

Earl wrote:
>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.


"Raaj" <ra***********@yahoo.comwrote in message
news:11**********************@80g2000cwy.googlegr oups.com...
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.

Earl wrote:
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?

Dec 21 '06 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

14
by: Axel Straschil | last post by:
Hello! Im working with new (object) classes and normaly call init of ther motherclass with callin super(...), workes fine. No, I've got a case with multiple inherance and want to ask if this...
14
by: Michael Winter | last post by:
In an attempt to answer another question in this group, I've had to resort to calling the DOM method, Node.removeChild(), using a reference to it (long story...). That is, passing Node.removeChild....
6
by: jalkadir | last post by:
Let's say that I have this class: class Parent{ private: char* str; public: const char* getStr(){return str;} }; And then I create a child class class Child{ private: std::string str;...
2
by: Andrea Gavana | last post by:
Hello NG, this may seem a stupid (or even impossible) question, but my knowlegde of Python is quite limited. I have basically a simple graphical user interface that contains a Panel, another...
28
by: Jon Davis | last post by:
If I have a class with a virtual method, and a child class that overrides the virtual method, and then I create an instance of the child class AS A base class... BaseClass bc = new ChildClass();...
5
by: Dave Veeneman | last post by:
I'm using inheritance more than I used to, and I find myself calling a lot of base class methods. I generally call a base method from a dreived class like this: this.MyMethod(); I'm finding...
5
by: Randy | last post by:
The following code, which runs when I click File->Save in my main form, finds my save button in my mdi child for just fine. The question is: how do I invoke the Save method in the child form? ...
0
by: Carlitos | last post by:
Hi there, I apologize if it is not the right forum to post this question, but it has to do with C#, HTML and javascript altogether. I programmed a windows form custom control in C# which...
1
by: =?Utf-8?B?cmFuZHkxMjAw?= | last post by:
The code below is pretty simple. Calling Talker() in the parent returns "Parent", and calling Talker() in the child returns "Child". I'm wondering how I can modify the code so that a call to the...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.