Returning values from a form

[Dan Tallent]

I have an application I'm working on where one form will open another.
This newly opened form needs to return a value based on the users actions.
My forms are not modal. I have seen discussions about overridding the
DialogResult, however I believe this will only work in a modal form
situation.

I have code where I've added a custom event to the child form called
ReturnValueSet. The form that opens this form can then subscribe to this
event and trap the value that was set if it wishes. The child form then
must be coded to raise this event when it is closing. This method works,
but I would prefer to use a more standard approach is there is one.

Does anyone have suggestions?

Thanks
Dan

 

[Dan Tallent]

Thanks for the quick response.

If I use the FormClosed event does this cause a potential issue that the
form may of already been released and therefore the property being
unavailable?

If using the FormClosed event is safe, do you know if the code within the
child forms FormClosed event fires before it raises the event to the parent?

Thanks
Dan

[...]
I have code where I've added a custom event to the child form called
ReturnValueSet. The form that opens this form can then subscribe to
this
event and trap the value that was set if it wishes. The child form then
must be coded to raise this event when it is closing. This method
works,
but I would prefer to use a more standard approach is there is one.

If you just want the client form to retrieve the value when the child form
is closed, then I'd say the client form should just subscribe to the
FormClosed event. Then the child form should set some property that the
client form can retrieve when the FormClosed event is raised (the child
form would of course make sure this property is suitably set when it's
closed, before the FormClosed event is raised).

That said, other than the name of the event, what you've done is actually
a reasonably standard approach, depending on the semantics you want. The
.NET convention would be to have a property, and then an event with the
same name as the property, plus "Changed".

You could either only raise the "Changed" event when the form closes, or
you could allow for the client form to monitor changes as the user
provides input. Either way, that would be reasonable too.

Pete

 

[Family Tree Mike]

Your client (or parent) form won't have released the instance, so the
instance count is not zero, and therefore it is not disposed. You won't
have an issue getting a property on the object from your instance.

Thanks for the quick response.

If I use the FormClosed event does this cause a potential issue that the
form may of already been released and therefore the property being
unavailable?

If using the FormClosed event is safe, do you know if the code within the
child forms FormClosed event fires before it raises the event to the
parent?

Thanks
Dan

[...]
I have code where I've added a custom event to the child form called
ReturnValueSet. The form that opens this form can then subscribe to
this
event and trap the value that was set if it wishes. The child form
then
must be coded to raise this event when it is closing. This method
works,
but I would prefer to use a more standard approach is there is one.

If you just want the client form to retrieve the value when the child
form is closed, then I'd say the client form should just subscribe to the
FormClosed event. Then the child form should set some property that the
client form can retrieve when the FormClosed event is raised (the child
form would of course make sure this property is suitably set when it's
closed, before the FormClosed event is raised).

That said, other than the name of the event, what you've done is actually
a reasonably standard approach, depending on the semantics you want. The
.NET convention would be to have a property, and then an event with the
same name as the property, plus "Changed".

You could either only raise the "Changed" event when the form closes, or
you could allow for the client form to monitor changes as the user
provides input. Either way, that would be reasonable too.

Pete

 

[Dan Tallent]

Sounds good.. now I have a plan.

Thanks
Dan

Your client (or parent) form won't have released the instance, so the
instance count is not zero, and therefore it is not disposed. You won't
have an issue getting a property on the object from your instance.

Thanks for the quick response.

If I use the FormClosed event does this cause a potential issue that the
form may of already been released and therefore the property being
unavailable?

If using the FormClosed event is safe, do you know if the code within the
child forms FormClosed event fires before it raises the event to the
parent?

Thanks
Dan

[...]
I have code where I've added a custom event to the child form called
ReturnValueSet. The form that opens this form can then subscribe to
this
event and trap the value that was set if it wishes. The child form
then
must be coded to raise this event when it is closing. This method
works,
but I would prefer to use a more standard approach is there is one.

If you just want the client form to retrieve the value when the child
form is closed, then I'd say the client form should just subscribe to
the FormClosed event. Then the child form should set some property that
the client form can retrieve when the FormClosed event is raised (the
child form would of course make sure this property is suitably set when
it's closed, before the FormClosed event is raised).

That said, other than the name of the event, what you've done is
actually a reasonably standard approach, depending on the semantics you
want. The .NET convention would be to have a property, and then an
event with the same name as the property, plus "Changed".

You could either only raise the "Changed" event when the form closes, or
you could allow for the client form to monitor changes as the user
provides input. Either way, that would be reasonable too.

Pete

 

[Family Tree Mike]

Peter, I think I follow what you are saying, but didn't realize that was
happening behind the scenes. Thanks for educating me today!

Mike