InvalidOperationOperationException problem

[Jeroen]

I've posted a related question in this newsgroup before, see google
groups link:

http://groups.google.nl/group/micros...8051941dd4e2c4

We still experience the problem ever since we migrated from .NET 1.1
to 2.0. Some of the causes (amongst others bad code in destructors)
have been removed, drastically reducing the number of appearances of
of the dreaded 'InvalidOperationException' right after closing the
application.

However, our testers sometimes get an InvalidOperationException
without clear trace (it occurred in 'System.Windows.Forms', pffff)
when they have just closed the application.

My question then is, can you guys help me compile a list of possible
sources for the above kind of problem? To start of with the ones we
already caught:
- Starting new screens/dialogs/forms in destructors;
- Incorrectly disposing a WebBrowser control
- Meddling with the parent of a form
- ....?
Any suggestions would be appreciated

[Nicholas Paldino [.NET/C# MVP]]

Jeroen,

Looking at your old post, you should not have to do anything in your
Dispose method if all you are doing is disposing of the WebBrowser control.
When the form closes, a close message is sent to all the controls that are
hosted in the form, and disposed of. The overriding of the Dispose method
isn't needed, unless you need to do something else.

The reason you were getting InvalidOperationExceptions in your
finalizers is because you were trying to perform UI operations from the
finalizer. The UI operations have to be performed on the thread that
created the control, and the finalizer runs on its own thread.

Are you doing any other funky things in the finalizer we should know
about?
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Jeroen" <me******@gmail.comwrote in message
news:11**********************@l70g2000hse.googlegr oups.com...

I've posted a related question in this newsgroup before, see google
groups link:

http://groups.google.nl/group/micros...8051941dd4e2c4

We still experience the problem ever since we migrated from .NET 1.1
to 2.0. Some of the causes (amongst others bad code in destructors)
have been removed, drastically reducing the number of appearances of
of the dreaded 'InvalidOperationException' right after closing the
application.

However, our testers sometimes get an InvalidOperationException
without clear trace (it occurred in 'System.Windows.Forms', pffff)
when they have just closed the application.

My question then is, can you guys help me compile a list of possible
sources for the above kind of problem? To start of with the ones we
already caught:
- Starting new screens/dialogs/forms in destructors;
- Incorrectly disposing a WebBrowser control
- Meddling with the parent of a form
- ....?
Any suggestions would be appreciated

[Marc Bartsch]

Hi Jeroen,

- Starting new screens/dialogs/forms in destructors;
- Incorrectly disposing a WebBrowser control
- Meddling with the parent of a form

I am interested in what you mean by "Meddling with the parent of a form". Could you elaborate on this or send a link with more information? I had similar problems in the past and never found out what my problem was.

Thanks a lot and best wishes,

Marc.

[Jeroen]

Are you doing any other funky things in the finalizer we

should know about?

We had code that showed a messagebox with an exception message, as
executed from the ~ method. Removal of that code reduced the number of
InvalidOperationException appearances. Nothing further there though.

I am interested in what you mean by "Meddling with the parent
of a form". Could you elaborate on this or send a link with more
information? I had similar problems in the past and never found
out what my problem was.

In our case we had a static variable reffering to a dialog form. A
static method could be called anywhere from the application to show
the dialog, passing (if applicable) a form reference that would act as
a parent to the dialog form. To achieve some specific GUI behavior we
set the dialog 'Owner' property to the passed form ("meddling with the
owner"), which sometimes led to InvalidOperationExceptions.