MDIChild change other MDIChild objects

I appreciate what you have said Sam and understand that some need the money aspect to help so I do not begrudge you on that.

So that you and others can better understand the role that MDI can play in any application I have started putting together an MDI forms management framework which people on this forum will be able to implement very easily.

The code will be there and as long as my copyright info remains in the files I wont care who uses it.

The premise of the forms management is that it does not care about the type of form you want to instantiate, the business logic should know what to do with those forms when and if they are created.

This will be explained as an article using forms to open CSV's in a DataGrid without odbc or other dll's then saving the edited values of the CSV's.

It will take a day or two.

I believe you that are not in this for the points.
 
I am also interested in learning. We can continue this discussion elsewhere, in a forum in which design is the designated topic and there are people with more experience than we have in the area of design. I don't have as much time to spend as I would like to, but it would be more appropriate to continue this discussion in a more relevant forum.
 
I also am not expressing my opinion for the purpose of making points, but unlike you, I do need the money so I wanted to get in a couple of artlicles before the end of the month. I need to go and do that.

I understand what you say Sam the D in MDI is document and that implies a document of the textual kind but MDI is used for much more than textual documentation it is also used in accounting application, imaging applications, spread sheets like XL, IDE's like C#, C++ VS++ etc..

Yes in the original design it was not imagined the power of MDI to do the things I have outlined this is why programming has progressed, people (programmers) thought up different ways of doing things better and MDI is certainly a better way of managing an applications potential of allowing 400 odd forms that Giorgio wants to manage with a tree view.

If Georgio has not already discovered this, he will soon, a tree view anchored in an MDI is NOT a good idea so he will need to have it in a child form which should then communicate with the parent to initiate the menu like behavior he is looking to achieve. But then this is probably why he is talking about MDI Children.

I am not saying he has to do this but it is the MOST efficient way.

Using worker classes his child forms can have minimalistic code making it easier to manage all round.

Worker classes can have the global functions used by ALL forms to load data into grids, list boxes or combo boxes they can also contain the record structures and a heap of other useful stuff. 

Another point I would like to make is that Georgio's need to use a tree view to  instantiate forms the way that has been established is indicative of his ability to learn better ways of doing things so why say it is too easy to go down the path of MDI management!

Anyway no disrespect to you Sam, but this is about learning and you have given good examples and some bad examples and I know that maybe some of the examples I have given are / were not up-to scratch either but I am not about scoring points and in fact when I received an email from this forum saying that I had won some money for my contributions I replied and told them to donate it to a charity as I had no need of the money. This can be verified by the forum admin if you like.

You said: "My understanding of MDI is that you can open form x,  X number of times". It is your understanding that MDI was designed for multiple forms to be used. It however is not called "Multiple Window Interface"; it is called "Multiple Document Interface", designed to support multiple documents. In the original design of MDI, there is not much need to share most of the data shown in the the child windows.
 
So we are at the point where we are repeating ourselves, so I will likely refrain from other comments on this subject in this thread. I hope others will understand that absence of further comments on this subject in this thread does not imply I was convinced.

I am astounded,

I am not sure that you understand what the concept of an MDI is, if you are embarking on a journey to create an MDI application then you need to design it around MDI concepts and that means that the MDI parent MUST marshal operations.

My understanding of MDI is that you can open form x,  X number of times and have x number of different records from the same table open at any given time, these MUST be managed by the MDI parent that is how ALL MDI's work.

If they did bnot intend for it to work that way then there would be no need for MDI's in the first place.

it's no good saying 'It is too easy to start on that path and by the time you realize it is not the most efficient use of development time" it is not about efficient use of development time, it is about efficient development of an application and if that means it takes a little longer to accomplish then so be it.

The shortest way can sometimes take you on the longest journey don't you think?

And my first introduction to computers was with punch cards way before IBM's XT and Hitachi's Peach and Vic 20 and btw, I learn new things every day.

Ps, I have known 'system design experts' who did not have a clue how to design systems that 'users' wanted to use. just because a systems 'x-spurt' would not do it in a particular way does not mean that it is wrong to do it that way.

There is nothing simple about generating code to create a form.

When I write applications I write functions once and use them many times, the example i gave is just one such example and it does not necessarily need to be on a form  and in fact I put list load functions like the example in a class of its own.

It is far easier and more efficient to use the MDI parent form to marshal requests to its children than you think.

Each form has it's own code to do what ever it is designed to do but if you want to update other forms with the changes made on the form you are on then do that via the MDI parent, let it tell the other forms that changes have been made and that they should update if they need to that is the basis of the Windows BROADCAST function.

When windows is shutting down it broadcasts a message to all other windows applications to shutdown doing their house work before closing, widows does not need to know what the applications do just that they respond to the shutdown request.

This is the same principle that I use when I write MDI applications, you broadcast and if they need to do anything they do otherwise they do nothing..


 

theLizard: Using the parent in the manner you suggest as in "formX.fillMyListbox(formY.ListBoxAlias)" is more complicated than what I suggested. There might be a good reason to do that, but I provided the simplest solution and hopefully that is all that is needed.
 
There is a popular design theory that I think is called Business Logic, in which there is a Data Access Layer, a Business Logic Layer and a UI layer. I certainly agree with the fundamental concept of separating the UI from the main logic. It is very worthwhile to learn, and it helps to start simple. Sure it seems easier to use forms as containers, but what often happens is that software starts simple then grows to be more useful. Developers often start with something that is easy at the beginning but then the complexity grows such that the simple solution becomes a mess to improve.
 
I suppose that you also criticize Microsoft for generating so much code for something as simple as a form. Yet simple forms can be made quite complicated without significantly more code. I hope I am orienting Giorgio in a direction that will simplify development in the future when things do get complicated.

Since your 'Control' form is the MDI  itself and it has knowledge of all its children and all the children have knowledge of the parent let the parent marshal the actions you want to perform on the objects based on the child's request.

The child forms need not know anything about the other forms you may have unless you have a specific need to.

Seems that a lot of people on this forum want to go about things the hard way, if you want to access the properties and events of an object on a form all you need to do is declare a public alias to the object.

If you want a form (any form) to fill a list box or combo box or anything else the other form does not need to know who the owner of an object is, all it needs to know is the object type.

if you have a public function in form x that fills list boxes (any list box)  and you want a list box in form y filled by form x you simply send the reference of the list on form y to form x via the MDI parent

formX.fillMyListbox(formY.ListBoxAlias);


in this example, whatever you do to the alias is done to the actual list box on your other form, it's like parsing pointers to the objects rather than instantiating new objects.

in other words if you do this

public ListBox alias = listbox1;  //alias is not a new object just a ref to listbox1

alias.text = "whatever"

listbox1.Text wil also be "Whatever"

 
I hope this answer is not too advanced.

Sam:
 
Thanks for your input. I know I am probably using the wrong terminology.
 
I really dont want to have all forms access the other forms. But, I have a 'Control' form that can change or access stuff on other forms.
 
I will study your last post... I think there is something I can use there.

It is possible for every form object shown in the application to be accessible from any form, but that is not good design. If you can explain accurately why you need to do that then we can help you with that but my guess is that our time is better invested by pursuing the design I am describing, or something similar.
 
Note that developers often say "project" when they should say "application". Project implies source code and therefore the source-code definitions of forms, whereas application refers to execution. An executing application can have many instances of a form even if there is just one definition of it.

To create a constructor that sets teh document object, change:

public Form1()
{
InitializeComponent();
}

To:

public Form1(Document doc)
{
InitializeComponent();
this.doc = doc;
}

Also in the form, create a member variable such as "Document doc".

Sam:
 
I sort of think I understand. I will study it and try what you are saying... Thanks
 
I guess what I was hoping for is not possible. I just wanted every form object in the project to be accessible from any form.

Nainil:
 
Thanks for the reply...but I dont understand...LOL...Sorry.
 
Do you know where I can find a sample of code?

Hi Giorgio,
        While instantiating a new MDI child from the MDI Parent form, save the reference of the MDI child1 in probably an ArrayList or an Array. Now in MDI child2, you should first access the MDI parent, iterate through the ArrayList (from the MDI Parent), get the wanted MDI child (in this case it will be MDI child1) form from the ArrayList and then you can change the object in MDI child 1. Hope this helps.