Owned forms in MDI Apllications

J

Juan M. Cervera

I am developing a mdi application, and I would lke to make one MdiChild form
owned by another MdiChild form.
Is it possible ?

I make something like this in the first form (owner form) to open the other
(owned form)
I woluld like they behave like owned and continue being mdi children forms.

OwnedForm owned = new OwnedForm ();
owned .Owner = this;
owned .MdiParent = this.MdiParent;
owned .Show();

The problem is the form is not owned anymore after setting the MdiParent
property

Can anybody help me with this?
Thank you in advance

Juan M. Cervera
 
J

Juan M. Cervera

Nobody can help me with this ?
Nobody has any idea?
I really want to solve this issue.
PLEASE.

Thanks
 
J

Juan M. Cervera

Hi Ulrich,
What I pretend is to build an MDI enterprise application. Each form (p.e
customers, products , ...) will be a mdichild form inside the application,
but I would like that some of them would be related.
A CustomerListForm and a CustomerEditForm will be related so if I change the
selected row in the list, it will change the customer viewed inth edit form.
And I would like also to close the two forms when I close the list form.
I think I can do this with a variable in the list form referencing the edit
form, but is anoying not to use something like the Owner Property of the
form for that.
I begin to think this is impossible in mdi applications, because the owner
of a mdichild form can only be its MdiParent form., no?

Thanks
 
J

Jay B. Harlow [MVP - Outlook]

Juan,
As Ulrich asked, what are you trying to achieve.

A Win32 window can only have one owner, when you set the MdiParent property
of a form the 'MdiParent' becomes the owner. I'm not sure if its a direct or
indirect relationship, as Win32 uses a MdiClient window for MDI apps. The
..NET MdiChild, may actually be owned by an underlying MdiClient object.

Hope this helps
Jay
 
U

Ulrich Sprick

I see.

You must distiguish between GUI design and the application's functional design. The environment enforces rules that e.g. MDI apps
have to "obey", so MDI childs are children of the parent...

Suggestion:
Design your forms as ordinary mdi children.
1. In the list form, create an event that fires if the customer changes.
2. In the detail form, create an event handler that handles customer changes.
3. When you instantiate the detail form, hook the event handler of the detail form into the event of the list form.

You can create an event argument class derived from System.EventArgs, that carries a reference to the current row. The listform
raises the event and passes the row, and each subscriber of the event (there might be other forms similar to the details form...)
receives the row reference in the event handler, and can now display the appropriate content in the UI.

The design is flexible enough to build your "enterprise components" (I hope).

The glue logic, child forms arrangement and positioning for example, is then left to the application, and thus the layout is
separated from the functional components.

Did this put you on the tracks?
Ulrich
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top