Using Show() and not allowing more than one instance

[RvGrah]

I've looked (probably too briefly) at using the singleton class, and
I'm at bit worried about that approach, so I'm using another one.

In my parent form, which is just a form with buttons to launch
individual modules that do the actual work in a PO system, I create a
variable for each child form it might open. Each child form has a
declare in the form of:

public frmPoMain myDad;

and when any child form is launched, the parent form checks to see if
the form already exists, and if not creates and launches it:

if (fChoose == null)
{
fChoose = new frmChoosePO();
fChoose.myDad = this;
}

fChoose.Show();
fChoose.BringToFront();

In the child form, in the FormClosing event, it sets the parents
reference to null so the parent will know whether to create and show
the form, or only to show it.

This works fine, but is there a simpler way of doing this that doesn't
involve passing public variables back and forth between the child and
parent? It seems a bit fragile the way I'm doing it, but maybe I'm
just being paranoid. I don't want to use ShowDialog() because my users
sometimes need several child windows available at the same time.

Bob Graham

 

[Rob Whiteside]

I've looked (probably too briefly) at using the singleton class, and
I'm at bit worried about that approach, so I'm using another one.

In my parent form, which is just a form with buttons to launch
individual modules that do the actual work in a PO system, I create a
variable for each child form it might open. Each child form has a
declare in the form of:

public frmPoMain myDad;

and when any child form is launched, the parent form checks to see if
the form already exists, and if not creates and launches it:

if (fChoose == null)
{
    fChoose = new frmChoosePO();
    fChoose.myDad = this;

}

fChoose.Show();
fChoose.BringToFront();

In the child form, in the FormClosing event, it sets the parents
reference to null so the parent will know whether to create and show
the form, or only to show it.

This works fine, but is there a simpler way of doing this that doesn't
involve passing public variables back and forth between the child and
parent? It seems a bit fragile the way I'm doing it, but maybe I'm
just being paranoid. I don't want to use ShowDialog() because my users
sometimes need several child windows available at the same time.

Bob Graham

Sounds like you want ought to simply subscribe to the closing event of
the child form then you could reset your variables from within the
parent:

if (fChoose == null)
{
fChoose = new frmChoosePO();
//fChoose.myDad = this;
fChoose.FormClosed += new FormClosedEventHandler
(fChooseWasClosedHandler)
}

fChoose.Show();
fChoose.BringToFront();

 

[rvgrahamsevatenein]

Sounds like you want ought to simply subscribe to the closing event of
the child form then you could reset your variables from within the
parent:

 if (fChoose == null)
 {
     fChoose = new frmChoosePO();
     //fChoose.myDad = this;
     fChoose.FormClosed += new FormClosedEventHandler
(fChooseWasClosedHandler)
 }

 fChoose.Show();
 fChoose.BringToFront();

So you're saying VS will allow me to create a procedure in my parent
form that will be triggered by an event in the child? This makes
sense, I just didn't realize that events/procedures could cross the
form's code boundaries so to speak. Thanks for the input!

Bob

 

[rvgrahamsevatenein]

Tried it and it works great!

Sounds like you want ought to simply subscribe to the closing event of
the child form then you could reset your variables from within the
parent:

 if (fChoose == null)
 {
     fChoose = new frmChoosePO();
     //fChoose.myDad = this;
     fChoose.FormClosed += new FormClosedEventHandler
(fChooseWasClosedHandler)
 }

 fChoose.Show();
 fChoose.BringToFront();

 

[Pavel Minaev]

So you're saying VS will allow me to create a procedure in my parent
form that will be triggered by an event in the child? This makes
sense, I just didn't realize that events/procedures could cross the
form's code boundaries so to speak. Thanks for the input!

Aside from everything Peter said, you should keep in mind that C#
events are not in any way specific to UI. Any object can declare an
event (and a class can declare a static event), and any method in any
other object (or a class, if it's a static method) can serve as an
event handler for that. The only limitation is the accessibility level
(private/protected/...) of the event, and the availability of object
instance. It's a very general-purpose mechanism

 

[rvgrahamsevatenein]

Thank you for the additional information. I admit I was frightened
away from the singleton approach because the help files said it could
cause issues with multi-threaded apps. I don't know if this qualifies,
but some of my forms use BackGroundWorkers to execute dome data access
functions, and also I use a lot of Infragistics controls that I know
have some multi-threading in them. Do either of these possibly
interact with the singleton approach, or am I over-analyzing while
under-understanding?

Are there any reasons why using the singleton approach is better than
subscribing to the FormClosed event?

Bob

Aside from everything Peter said, you should keep in mind that C#
events are not in any way specific to UI. [...]

Exactly.  By "the primary reason for events", I meant the aspect where  
code in one class can be executed at the appropriate time by another  
class.  The immediate example is of course UI code, but I hope my post  
didn't seem to imply that it's the support of UI code that is why events  
exist.  They are useful in a great deal of other contexts as well.

Pete