Disposable & 3rd Party Lib & GUI

[davis]

Hi,

I'm wrapping a 3rd party .NET 2.0 CF library which mandates Dispose be
called.

So, I mandate Dispose be called on my library...I follow the Disposable
pattern described on MSDN...and I Dispose of the wrapped 3rd party
library in there.

My library is meant to be used in Forms.

My question is simply -- what's the proper way to shut down a form?
There is:

~ destructor

<form>_Closing( )

<form>_Closed( )

should I call one of the following, and if so...where...->

Application.Exit( );

this.Close( );

Where should I issue the Dispose( ) on my library?

[Virgil Dupras]

davis wrote:

Hi,

I'm wrapping a 3rd party .NET 2.0 CF library which mandates Dispose be
called.

So, I mandate Dispose be called on my library...I follow the Disposable
pattern described on MSDN...and I Dispose of the wrapped 3rd party
library in there.

My library is meant to be used in Forms.

My question is simply -- what's the proper way to shut down a form?
There is:

~ destructor

<form>_Closing( )

<form>_Closed( )

should I call one of the following, and if so...where...->

Application.Exit( );

this.Close( );

Where should I issue the Dispose( ) on my library?

I see you suggest Application.Exit in your list. Does it mean that your
form is only closed when the application shuts down? In this case, I
don't think you even need to call Dispose(). Resources will all be
freed when the application is shut down.

[davis]

Where should I issue the Dispose( ) on my library?

I see you suggest Application.Exit in your list. Does it mean that your
form is only closed when the application shuts down? In this case, I
don't think you even need to call Dispose(). Resources will all be
freed when the application is shut down.

Hi Virgil, this is not the case...especially in the compact framework
(at least what I have found). Getting an application to really exit
seems a tricky endeavor especially when you are using unmanaged
resources.

My library uses System.IO.Stream as the means to communicate directly
with the underlying hardware that is exposed from the 3rd party
library.

The 3rd party library mandates Dispose be called only once and when the
application exits. If it is called twice it throws
ObjectDisposedException.

If it is not called and the process unexpectedly terminates, then the
internal state machine of the hardware gets all screwed up and may
require a hard reset of the device. This really stinks, but this is
the way it is as I have no insight into the 3rd party code. So I have
to protect for all measures where the application terminates via any
kind of exception and make sure this doesn't happen.

This is why I implemented the Disposable pattern as per the example
here http://msdn2.microsoft.com/en-us/lib...isposable.aspx

On the main UI form, there is a Window Style -MinimizeBox property.
In CF, when set to True, the app does not terminate when the X button
is pressed, but it hides it. If set to false, it changes the X to an
Ok icon...and when pressed it is supposed to terminate.

Thus, in Form_Closing( ) I call my libraries Dispose( ), which in turn
calls the 3rd Party Library Dispose( ) -- and hope it works...but when
I run the remote process viewer on the device, I see the .exe is still
running, and not sure why...which led me to ask my original question --
what is the recommended practice here?

[Virgil Dupras]

davis wrote:

Where should I issue the Dispose( ) on my library?

I see you suggest Application.Exit in your list. Does it mean that your
form is only closed when the application shuts down? In this case, I
don't think you even need to call Dispose(). Resources will all be
freed when the application is shut down.

Hi Virgil, this is not the case...especially in the compact framework
(at least what I have found). Getting an application to really exit
seems a tricky endeavor especially when you are using unmanaged
resources.

My library uses System.IO.Stream as the means to communicate directly
with the underlying hardware that is exposed from the 3rd party
library.

The 3rd party library mandates Dispose be called only once and when the
application exits. If it is called twice it throws
ObjectDisposedException.

If it is not called and the process unexpectedly terminates, then the
internal state machine of the hardware gets all screwed up and may
require a hard reset of the device. This really stinks, but this is
the way it is as I have no insight into the 3rd party code. So I have
to protect for all measures where the application terminates via any
kind of exception and make sure this doesn't happen.

This is why I implemented the Disposable pattern as per the example
here http://msdn2.microsoft.com/en-us/lib...isposable.aspx

On the main UI form, there is a Window Style -MinimizeBox property.
In CF, when set to True, the app does not terminate when the X button
is pressed, but it hides it. If set to false, it changes the X to an
Ok icon...and when pressed it is supposed to terminate.

Thus, in Form_Closing( ) I call my libraries Dispose( ), which in turn
calls the 3rd Party Library Dispose( ) -- and hope it works...but when
I run the remote process viewer on the device, I see the .exe is still
running, and not sure why...which led me to ask my original question --
what is the recommended practice here?

Well then, I'm clueless (I'm kinda new to C# and .NET). Maybe that your
3rd party library didn't implement the finalizer of their IDisposable
correctly (because it is supposed to call Dispose(false), and if it
did, well, as I wrote in my other message, you wouldn't even have to
call Dispose()).

Maybe The problem isn't with the Dispose(), but with some invalid stuff
you perform with the hardware that messes things up? Or with the order
in which stuff is disposed in your app?

Anyway, to answer you question, personnally, I put application's
initialization code in Program.Main(), before the "Application.Run(new
MainForm());" line, an the finalization code after that line. I
wouldn't put application level finalization in Form_Closing(), it
doesn't seem proper to me. There may be cases where this isn't called
(wild guess here, I'm not sure).