Disposing Form and Returning a Class Member

  • Thread starter Thread starter Klaus Löffelmann
  • Start date Start date
K

Klaus Löffelmann

Hello,

I just stumbled over a piece of code, and am not sure, if this is safe.
Suppose, you have a form with a class member, which holds the value for a
certain procedure to return to the calling instance. This procedure should
also close and dispose the form.

In this case, would it be safe to dispose the form before returning the
result?

Me.Dispose() ' close/dispose the Form
Return Items ' item is a form member; is there a chance, that it
is GCed, yet?
End Function
 
* "Alok said:
I would suggest the following:
Try
Return Items

Catch

Finally
Me.Dispose()
End Try

hope that helps :)
Click to expand...

That's not the answer to the question.

The question was (AFAIU): Is it safe to access instance members of a
Windows Form after disposing it.
 
Alok,

thanks for your help - I appreciate that.
But actually Herfried is right. It's not, that I don't know how to avoid
this construct.
I just want to know, if it *was* OK to do it that way.
I'd be glad, if people could tell their opinion, even if they didn't know
exactly
(We should have more discussions here, anyway, shouldn't we? ;-)
In my opinion, this construct actually should be safe, since the GC wouldn't
start before the program left that particularly code of the form class?!

Klaus
 
I would suggest the following:
Try
Return Items

Catch

Finally
Me.Dispose()
End Try

hope that helps :)
 
In my opinion, instance members shouldn't be called after the form has been
disposed.
given the non-deterministic nature of GC, you are not entirely sure if the
resources have been re-claimed or not. in case, there is a demand for memory
the gc could collect un-referenced objects immediately.

in either case, i don't think the form should dispose itself off. That
should be the prerogative of the calling assembly.
Any comments ??
 
Alok,

the problem is: closing a form leads automatically to a Dispose. So, can I
be sure that returning a form member after I closed a form is safe? And
Close is definitly a prerogative of the form, don't you think?
Having said that, Close causes Dispose only indirctly via a SendMessage
(correct me, if I'm wrong), so it could be safe again, since the SendMessage
can only be processed with the next Idle-State of the application, and that
can't be the case, before the return value has been actually returned!?

Klaus
 
Alok,

just two questions about that:

Alok said:
Hi Klaus,
Firstly I would like to re-iterate that the form himself shouldn't decide
whether to close or not. the controller should decide that. The controller =
calling form. Just because a Close() method has been supplied, doesn't mean
that the form should dispose itself whenever it feels like !!!
if that was the case, our application would start acting like the Windows
blue screen :)
Click to expand...

What about modally shown forms? (if the called form doesn't close, who
does?)
What, if the user clicks the control box' close button? (In that case, the
form itself is the closing instance, too)?
you might also want to look into Value types and reference types. With
reference types, you might have a problem.
if you start looking at the message queue then the Close message would be
ahead of return method right ??
in which case, does it make sense returning the variable if it is a
reference type ??
Click to expand...

Sorry, you lost me there.
Maybe, I didn't make myself clear enough - let me try again:
This is what happens form-internally, when a form is Closed:
1. Procedure calls "Form.Close"
2. Form sends "WM_Close" with its own handle via SendMessage to Message
Pump.
3. Form Returns Value (and, IMHO, that's still safe to do so, because the
form can't be disposed, yet)
4. Application reaches idle state
5. Message Pump is being processed.
6. Form receives WM_Close in WndProc
7. WndProc calles WMClose of Form.
8. WMClose calls Form.Dispose

So, it's safe to do it this way, isn't it? I mean: IMHO, it's absolutely
impossible that the message pump calls WndProc of the form (which eventually
disposes it), *before* the return value of the form has actually been
returned?
 
Hi Klaus,
Firstly I would like to re-iterate that the form himself shouldn't decide
whether to close or not. the controller should decide that. The controller =
calling form. Just because a Close() method has been supplied, doesn't mean
that the form should dispose itself whenever it feels like !!!
if that was the case, our application would start acting like the Windows
blue screen :)

you might also want to look into Value types and reference types. With
reference types, you might have a problem.
if you start looking at the message queue then the Close message would be
ahead of return method right ??
in which case, does it make sense returning the variable if it is a
reference type ??

-Alok
 
Hi Klaus,
Regarding the modal diaglog form, I agree upto a certain extent.
I would agree to your point only if it is a modal form. In that case also,
the form should not dispose itself until it's variable has been
de-referenced.

i.e. your form can be closed using close button or by clicking the 'X' on
the title. But still the calling form needs to de-reference it's variable,
right ??
 
Aloak,

Alok said:
Hi Klaus,
Regarding the modal diaglog form, I agree upto a certain extent.
I would agree to your point only if it is a modal form. In that case also,
the form should not dispose itself until it's variable has been
de-referenced.

i.e. your form can be closed using close button or by clicking the 'X' on
the title. But still the calling form needs to de-reference it's variable,
right ??
Click to expand...

actually no, because that is explicitely and exceptionally the job of the
Garbage Collector. A cleanup code like

objectvar = nothing

not only is unnecessary, it's slowing your program down needlessly.

Klaus
 
Back
Top