Which design pattern does this fall under??

[Richard]

Hi there,

Im using the Windows Media Player control on a windows form. When the
media it is playing ends, i want to use the playstate event to notify
the main MDI so that the Main MDI can close the player form, get the
next media item and load a new instance of the player form with the
new media.

(Theres other stuff going on so please dont reply suggesting i should
leave the existing player form open and just feed it new media).

My problem is when i do this exceptions get thrown that cannot be
caught such that the application fails. (ThreadContext errors etc)

I believe this is because the player form is the point of origin so to
speak, in that it raises the event which triggers the main mdi to
unload it and then try to load the new instance. In doing this the
Main Mdi actually kills the active thread that its trying to work on
because it came from the Player form... i hope i'm making sense.

Although i would specifically like an answer to my problem i figure
this must be handled by at least one design pattern because the
problem must crop up in all kinds of places - where an object A
creates an instance of Object B that needs to notify Object A when it
has completed some work load so that Object A can destroy Object B....
but how does Object A do this when the event that it is sinking from
Object B runs on the thread that Object A will need to do its work of
destroying B??

I figure someone goings to say something about delegates but isn't
that what events are implicitly anyway? I cant see how they would
provide the fix.

I also tried spinning up a new thread to destroy B but the results are
unpredictable.

Whew!!

TIA
Richard

P.S I also do not want to poll Object B from Object A.