If mdi child form is already opened

Question

I created an mdi application with mdi parent and several child forms. I have the following problem. If i try to open the same form the second copy of the form is created. But i want if a child form is already opened i would like it not to be created again but just getting the focus (becoming active form). Does anyboby know how to do this?

david 0 · Answer

Concepts for offering a guideline to implement code a certain way ... WRONG WRONG WRONG.... Consider: ======================== class X { private: X() {} X *s_X; public: X *Instance() { if (!s_X) s_X = new X; return s_X; } } ========================= class Y { private: Y(){} public: X *Instance() { Y *retVal=reinterpret_cast GlobalObjects::Get(Y); if (*retVal) { retVal = new Y; GlobalObjects::Put(Y retVal); } } ========================= class Z { private: Z() {} friend class Globals; } class Globals { private: static Z *g_Z; public: Z *GetZ { if (*g_Z) g_Z = new Z; return g_Z; } ============================ The following statements are all true. Class X only supports a Singelton instance. Class Y only supports a Singelton instance. Class Z only supports a Singelton instance. The implementations are completely different. NONE of the code is re-usable. Any programmer (familar with the Singleton pattern) can understand the following statements: Invoke a method on the singleton instance of X via X::Instance->Method(...) Invoke a method on the singleton instance of Y via Y:::Instance->Method(...) Invoke a method on the singleton instance of Z via Globals::Z->Method(...) The singletons could also be represented by references rather than pointers it would not change the fact that we are implementing the Singleton Design Pattern. What WOULD change if we did not use Design Patterns is the instructions to a user as follows: Invoke a method on the {really long tedious explaination} of X via X::Instance->Method(...) Invoke a method on the {really long tedious explaination} of Y via Y:::Instance->Method(...) Invoke a method on the {really long tedious explaination} of Z via Globals::Z->Method(...)

de_henny · Answer

[quote] Gamma [one of the authors of Design Patterns: Element of Resuable Software Design] specifically states that design patterns are NOT tied to any specific implementation. As such they are not concrete/tangible enties implemented in code but are rather simply concepts. [/quote] Concepts for offering a guideline to implement code a certain way. So that is why i say main purpose is not communication. However it is a great advance yes. Buy the way in the early 1983 i just was born ;) so i don't doubt your expertise. I just am stubborn and have lots to learn.

david 0 · Answer

Gamma [one of the authors of Design Patterns: Element of Resuable Software Design] specifically states that design patterns are NOT tied to any specific implementation. As such they are not concrete/tangible enties implemented in code but are rather simply concepts. Re-usable code [solutions] have been around since the advent of linkers that could join multiple portions of code into a single executable entity. Some of these library routines did in fact implement functionallity that can be described by contemporary design patterns. The limitation [which still holds true today] is that an implementation is constrained by many factors a concept is not. Lets look at a related issue. Many people think that virtual functions are someting that is new to object oriented programming languages. The reality is that the TERM is new but the capability is NOT. In early 1983 [over 21 years ago] I was part of a team developing software for the military. We hade a need to configure a program in an extremely dynamic fashion [ok it was extereme back then]. Our eventual design [which was not even 100% original back then] was published in tech journals under the title Runtime Variant Execution Paths using Structured Invocation Calls. What we described was the use of a C structure that contained both function pointers and other members. This structure could be passed into various functions which in turn would invoke the required operations by de-referencing the function pointers and passing arguments [tricky since C did not enforce signature matching!]. The full writeup was over 20 pages although most publications contained an abbrievated version. About 9 years later Bjarne put forth a language with would magically pass this structure to selected routines without explicit coding by the programmer. C++ was born. It allowed the human to think using a new paradigm and eliminate many of the hurdles of implementing certain concepts in a consise manner. Going back to Design Patterns.. Having a code library that allows a user to use string based commands passed to a globally accessable unary point for parsing and lexical analysis with which will create specific instances of different objects which will be passed back to the user can be a very handy set of tools to have but has NOTHING to do with Design Patterns. Using a Singleton Command Dispatcher to interact with a designated Object Factory is ALL about Design Patterns but does not refer to any specific programming language environment or implementation. It is when an actual collection of code is implemented that code re-use occurs. It is when a common lexigraphy is used [Design Patterns] that effective communication is achieved.

de_henny · Answer

Hey i can take criticism ;) . Besides i still have the excuse of being a new comer. But there is one thing i disagree with you [quote] The sole purpose of Design Patterns is to provide an efficient method of communicating an idea using a common lexicon. [/quote] I think that is indeed one of the advantages of design patterns. The sole purposes of Design Patterns is to describe relationships between objects and their functionality in such a way that re-use and extendibility can be contained. They offer solutions for problems every programmer runs into u number of times. And the funtionality described by these design patterns may have existed for years but i find it hard to imagine an implementation of a desgin patterns in non Object Oriented Programming Languages. Hell i doubt they even exist.

david 0 · Answer

Ahh the exuberance of a relative new-comer [de henny please dont take this too personally...]. Lets look at what a Design Pattern [note the capitalization] is and is not. A Design Pattern is a shorthand notation for a behaviour or group of related behaviours. The items in question are not per se a Design Pattern but rather are an implementation of a Design Pattern. The sole purpose of Design Patterns is to provide an efficient method of communicating an idea using a common lexicon. Lets look at an automobile. Specifically the big metal box that has a lot of moving parts which via one mechanism or another is able to transform the rotational speed of two shafts [usually in a co-linear avial relationship] in order to provide approriate speed and torque to the components connected to either end to promote eficient movement of the vechicle [or lack of movement via a disconnection of the rotational shafts. This device should also have the ability to reverse the rotational direction of one shaft relative to the other [with a common limitation that one of the shafts will always rotate in the same direction order to allow the vechile to travel in the opposite direction using a motive source which is only capable of providing a rotational output in a single direction. Clearly [ but definately not consisely] what we are talking about here is a transmission. Every one with even a very basic understanding of cars knows [sort of] what a transmission is. The word transmission [used in this context] is a simple lexical tool to communicate the above paragraph in a single word. Most fields have developed their own vocabulary. Mathematics has had forumlas which are well known by their name. Analytics has made use of well known named algorithms. Software Architecture is [in large part due to the efforts of the GoF] now starting to be able to express higher concepts using a terminology whict is rapidly becoming accepted. All of the functionallity described by Design Patterns has existed for years or even decades but the ability to communicate that said functionallity in a succient fashion is a welcome addition. Here endith todays lesson...

de_henny · Answer

I would never create a form as singleton cause what is the us of DMI then ;). I just gave a quick solution  and i aint that much experienced with design patterns ( finished college 3 weeks ago ). But the patterns i used helped me out so much i am trying to implement as much as them as possible. And indeed if u want to display more of the same type forms filled with different data then don't use a singleton. But in this case i didn't see anything of those requirements come back in the first thread so i thought let's start teaching design patterns on a simple way cause perhaps the other scares people off ;).

david 0 · Answer

de henny Thanks for the support! If you look at the code I pasted the FormFactory is in fact implemented using the Singleton Design Pattern. There are some interesting issues related to the implementations of a singleton. The biggest one is if the class is inherently a singleton or if the applications usage of a class only supports a single instance. Consiter an application which is designed to print to one and only one printer. A Printer class is written which handles all of the details. If the printer class in implemented as a singleton then the code could never be used in an application which needed to support multiple printers. If the concepts of a singleton is de-coupled from the class which provides the core functionallity additional flexability is achieved. To look at this in the context of the original application assume that one of the forms is CustomerContact and shows information about a specific customer. The application design rules indicate that there should be a way to display the information for the current customer using this form. If the form is implemented [directly] as a singleton problems will arise if/when a requirement is added to be able to display two customers [on different child forms] at the same time. If the CurrentCustomerContact functionallity implements the singleton capability then the basic form is free to be used in other situations in the future.

de_henny · Answer

The CPU wizard is right all are terrible work - arounds. Me myself just have started with C sharp for 6 months. But this problem will come in any programming language. Perhaps u should take a look at Design Patterns Instead of the code u could also create the Form Class as a Singleton. This means there can be only one instance of the class. For Example public class CConfig { private static CConfig instance = null; public static CConfig Instance() { if(instance==null) { instance = new CConfig(); } return instance; } protected CConfig() { // contructor logic here } } If u want an instance u now call CConfig cfg = CConfig.Instance(); u can specify a bool in the form class that keeps track if the form is showing. when u set the bool in the constructor u know it is only set once cause u used a SingleTon pattern. If the form is showing u then can call your method to make sure the form becomes the active form.

david 0 · Answer

asic1984...The other so-called solutions are many... 1) If the child form needs access to code in the main form then it can not be used in other areas. 2) If the parent form needs to have code that is specific to each of the child forms then it is not easily extensible. Remember ANY time you modify any piece of code you risk breaking it [I have actually opened files to copy a line of source accidently cut the line instead and introduced bugs that took HOURS to track down]. If you have excellent unit testing built into your design rules then this can be minimized but never eliminated. Making proper use of events and collections to implement a generic solution is significantly better than hard coding specific cases. The code I posted [if brought up to a full professional level of functionallity] could be placed in class library assembly and NEVER modified. Form classes would have no need to to know that they were managed to only have a single instance. The MDI parent document would not need to know that there was any work to be done to insure a single instance of the form. Write the code ONCE test debug and document it thoughly ONCE. Then proceed to use the code with confidence in many projects for a long time. I would like to suggest to all readers that they look a the work of Scott Meyers. Even though this material is based on C++ rather than C# most of the suggestions apply. Specifically 1) Program in the future tense 2) If you do not want to follow good O-O techniques go back to programming in [classic] Basic Cobol or Fortran.

asic · Answer

hi TheCpuWizard will ......when u found a solution with one line.............is it a poor solution will i respect your knopwledge ....and professional using of c#...........but why we refuse easy solutions .........just because it is not included in a style programming ?

david 0 · Answer

Doesn't any body DESIGN software. The solutions provided above are poor non-object oriented workarounds that would get a person fired in any decent company. The listing below if a very primitive version that still need a lot of work before being used in a production environment but at least has some elements of a resusable software design.... using System; using System.Collections.Specialized; using System.Reflection; namespace FormFactory { /// /// Summary description for FormFactory. /// public class FormFactory { private class FormList : System.Collections.Specialized.NameObjectCollectionBase { public void Add(System.Windows.Forms.Form frm) { BaseAdd(frm.GetType().ToString() frm); } public System.Windows.Forms.Form Get(string type) { return BaseGet(type) as System.Windows.Forms.Form; } } public static FormFactory FactoryInstance() { if (s_Instance == null) s_Instance = new FormFactory();; return s_Instance; } private static FormFactory s_Instance; protected FormFactory() { m_FormList = new FormList(); } private FormList m_FormList; public System.Windows.Forms.Form GetFormInstance(Type type) { System.Windows.Forms.Form retVal = m_FormList.Get(type.ToString()); try { if (retVal == null) { ConstructorInfo constructorInfoObj = type.GetConstructor( BindingFlags.Instance | BindingFlags.Public null CallingConventions.HasThis null null); if (constructorInfoObj != null) { retVal = constructorInfoObj.Invoke(null) as System.Windows.Forms.Form; m_FormList.Add(retVal); } } } catch (System.Exception exc) { exc = exc; } return retVal; } } }

maxon216 · Answer

Thank you! It works!

asic · Answer

hi as what i understand if your problem now is how to make variables in the frmMain.cs availabe in the child forms u can make this: define the variables in the main form by :static public ex: static public bool isClosed; so when u are now in the child form u can call it like this frmMain.isClosed=false; i wish that is this what u want

maxon216 · Answer

But the problem is when i really close the opened child form the value should be set to false or in my case the corresponding array member should be reseted to 0. And the problem is how to do this using Closing event on the child form. From this module the value declared in Main form module is not available (or to tell the truth i don't know how to access this variable). I don't know how to make variables from frmMain.cs to be available in other modules in my project. For example it was not a big problem in Delphi by using uses frmMain; in frmChild I failed to find similar method in Visual C#:( The code i posted previously works but after closing a child form it does not opens again as frms[] value still remains 1. Thanks

asic · Answer

hi will he could make a boolean variable that when he first click the child form creat button ..is set to true ....and if he clicked again and found that this variable equal true he just make it have focus.................. am i wrong?

maxon216 · Answer

Sorry but i'm new to C# and have no ideas how to use collection class. I tried to resolve my problem as follows: I declared array public int[] frms=new int[3] {000} ; in class frmMain() And wrote the following code: private void toolBar1_ButtonClick(object sender System.Windows.Forms.ToolBarButtonClickEventArgs e) { switch(toolBar1.Buttons.IndexOf(e.Button)) { case 0: if (frms[0]!=1) { frmGeneral newMDIChild0 = new frmGeneral(); newMDIChild0.MdiParent = this; newMDIChild0.Show(); frms[0]=1; } break; case 1: if (frms[1]!=1) { frmInvoices newMDIChild1 = new frmInvoices(); newMDIChild1.MdiParent = this; newMDIChild1.Show(); frms[1]=1; } break; case 2: if (frms[2]!=1) { frmPurchase newMDIChild2 = new frmPurchase(); newMDIChild2.MdiParent = this; newMDIChild2.Show(); frms[2]=1; } break; } } So when the any of the mdi child forms opens a corresponding value in the frms[] array becomes 1. For example for frmGeneral and frms[0]=1. But when that child form (frmGeneral) closes that value should be 0 (frms[0]=0). So tried to do this by writing a code for Closing event in the frmGeneral.cs file. But unfortunately frms[] declared in frmMain.cs is not available. How should i implement this? Thanks in advance

david 0 · Answer

asic1984....for one thing that would NOT do what the original poster asked..... Unless of course you think that clicking the disabled menu/button would magically bring the associated form to the front and transfer focus....

asic · Answer

hi why donnot u easly disable the button that crearts this child form when the first form is created and when this form is closed .....enable the button again

david 0 · Answer

Any type of collection class will do.

maxon216 · Answer

Thank You. But how can i create such list of forms?

david 0 · Answer

Keep a list of active child forms. Look in the list to see if the form is already open.