Lost Thread/Subprocess
in [Dot Net]
|
Prev: Nested for-each with external xml file (document('other.xml'))Issue
Next: Internet/email downloading/installation issues
From: Gregory A. Beamer on 26 Mar 2010 12:06 "Tobias Bergmann" <itistime115959(a)googlemail.com> wrote in message news:e9Q#DJAzKHA.2436(a)TK2MSFTNGP04.phx.gbl... > > I think the problem is: The background object still works even without the > calling object but when the IE is closed nobody tells the background > object that the hosting process was stopped. And so it suddendly acts > within non-allocated memory without a hosting process and that is what > causes a crash. The problem here is coding a user control as if it is partially a control and partially a Singleton. You would be better served to move the static bits to another object and use it as a Singleton (assuming it has application wide scope). If, instead, you need it to act like a Singleton per session, you need some more work on the model, but since you are closing IE, I am not sure that is your issue. A User Control is a UI element and should be used as a UI element. It is not designed to hold session-wide or application-wide state, so don't set it up that way or you will head for trouble. Separate out the other concerns, even if they are only used in the context of the user control. You can probably code something in the destructor of the control to cleanup the static variables, but this is just a bandaid for a bad design. -- Peace and Grace, Greg Twitter: @gbworld Blog: http://gregorybeamer.spaces.live.com ************************************************ | Think outside the box! | ************************************************
From: Tobias Bergmann on 30 Mar 2010 08:25
Hello Greg, the UserControl itself is just a UI and the object that is static is just a class/instance. This architecture was originally designed for a windows forms application and it worked very well. But then somebody had the idea to use it also within a web browser and it also worked. Just the little aspect that it causes an address access conflict when the IE is closed. The funny thing is that the destructor of the data cache class in the cackground is not called when the IE is closed so I can not release anything and that is propably tthe reason for the crash. I guess the IE is a different technology than pure .NET and so the static instance of data cache is somewhere running in the IE process but this process takes no care of it. That is why I decided to implement something like an close event of the own process. This code within the corstructor of my data cache class looks like that: myProcess = Process.GetCurrentProcess(); myProcess.EnableRaisingEvents = true; myProcess.Exited += new EventHandler(myProcess_Exited); But the myProcess_Exited event is never called when the IE is closed. But I can see that myProcess is realy the current hosting IE. I have the strange feeling that the IE has a sophisticated process structure and the GetCurrentProcess method just returns the handle to a certain part of the IE and this is not the part that tells me that the IE is closed... So I am still searching for a solution, even if you suggested to do a complete re-design of the architecture what is impossible at the moment. Thanks nevertheless Tobias "Gregory A. Beamer" <NoSpamMgbworld(a)comcast.netNoSpamM> schrieb im Newsbeitrag news:89E85B09-7225-4D7A-865C-7FC616632962(a)microsoft.com... > > > "Tobias Bergmann" <itistime115959(a)googlemail.com> wrote in message > news:e9Q#DJAzKHA.2436(a)TK2MSFTNGP04.phx.gbl... >> >> I think the problem is: The background object still works even without >> the calling object but when the IE is closed nobody tells the background >> object that the hosting process was stopped. And so it suddendly acts >> within non-allocated memory without a hosting process and that is what >> causes a crash. > > The problem here is coding a user control as if it is partially a control > and partially a Singleton. You would be better served to move the static > bits to another object and use it as a Singleton (assuming it has > application wide scope). If, instead, you need it to act like a Singleton > per session, you need some more work on the model, but since you are > closing IE, I am not sure that is your issue. > > A User Control is a UI element and should be used as a UI element. It is > not designed to hold session-wide or application-wide state, so don't set > it up that way or you will head for trouble. Separate out the other > concerns, even if they are only used in the context of the user control. > > You can probably code something in the destructor of the control to > cleanup the static variables, but this is just a bandaid for a bad design. > > -- > Peace and Grace, > Greg > > Twitter: @gbworld > Blog: http://gregorybeamer.spaces.live.com > > ************************************************ > | Think outside the box! | > ************************************************ |