471,605 Members | 1,545 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,605 software developers and data experts.

WindowsFormParkingWindow HELP

Hello all.

I have an app that is giving me problems on a WindowsXP x64 machine. When I
go to close the application the Main form closes, but when I look at
TaskManager the process still resides in the list.

Using SPY++ I can see that a "WindowsFormsParkingWindow" and ".NET
BroadcastEventWindow1.0.5000.0.1" are associated to my app by looking at the
Properties->Process Tab then selecting the ThreadID shows me my application
in the name field.

I do not have these problems on my WindowsXP Pro (32-bit) version.

I've read online that these can hold up a process when a control is removed
from a from it is "parked" onto the WindowsFormsParkingWindow if it happened
to have focus. But, in my case why do I not get the same behaviour on my
32-bit OS?

And what exactly constitutes "Removing" the control? Would having a control
on a tab and switching between tabs remove the the control?

Any ideas and help would be greatly appreciated!

TIA

Dennis
Feb 22 '06 #1
3 2707
Hi Dennis,
just a quick question, are you creating your own threads in this
application? If so, make sure you set the IsBackground property of the
thread to be true. If the thread is not a background thread then even when
you close your application GUI the non-background thread will still keep
processing and keep the applications process alive until it has finished.

There should not be any reason to see any difference between 64 and 32
bit OS versions, that is why I was wondering about the above bit.

Mark
--
http://www.markdawson.org
"Dennis" wrote:
Hello all.

I have an app that is giving me problems on a WindowsXP x64 machine. When I
go to close the application the Main form closes, but when I look at
TaskManager the process still resides in the list.

Using SPY++ I can see that a "WindowsFormsParkingWindow" and ".NET
BroadcastEventWindow1.0.5000.0.1" are associated to my app by looking at the
Properties->Process Tab then selecting the ThreadID shows me my application
in the name field.

I do not have these problems on my WindowsXP Pro (32-bit) version.

I've read online that these can hold up a process when a control is removed
from a from it is "parked" onto the WindowsFormsParkingWindow if it happened
to have focus. But, in my case why do I not get the same behaviour on my
32-bit OS?

And what exactly constitutes "Removing" the control? Would having a control
on a tab and switching between tabs remove the the control?

Any ideas and help would be greatly appreciated!

TIA

Dennis

Feb 22 '06 #2
Hi Mark,

What I have is an application that is using the Tao Framework (an OpenGL
library for .NET--built for 32-bit OS versions) within an MDI style Form,
with multiple controls and all sorts of other stuff. But, anyway, this
application I'm debugging with has a single instance of 1 of the controls.
The control does absolutely nothing, except Render when initialized and when
the Form is resized (I have it anchored to Top, Left, Right, & Bottom.)

Now, as for the Threads, I am not making any manually. Looking at
TaskManager however, the application once started shows 6 threads. When I
hit the Close button it drops to 1 and remains in the Processes list. BTW
this one thread starts taking up 25% of the CPU.

I agree with you Mark, there shouldn't be any difference between the OS
versions. So earlier we tried creating a new partition on the same maching
and moving the app over to XP Pro (32-bit). And we are experienceing the
same thing. It must be something to do with the hardware difference?

The problems are occuring on a machine with dual SLI video cards...could
this be the problem? I've run other applications that use the Tao custom
controls we've made and they do not respond the same as this particular
control. We have 2 controls currently that are behaving this way.

Thanks for thoughts though.

Dennis
"Mark R. Dawson" wrote:
Hi Dennis,
just a quick question, are you creating your own threads in this
application? If so, make sure you set the IsBackground property of the
thread to be true. If the thread is not a background thread then even when
you close your application GUI the non-background thread will still keep
processing and keep the applications process alive until it has finished.

There should not be any reason to see any difference between 64 and 32
bit OS versions, that is why I was wondering about the above bit.

Mark
--
http://www.markdawson.org

Feb 22 '06 #3
I've figured it out. Thanks anyway Mark.
It appears that our 2 controls giving us the problems with this were using
TexureMapping in OpenGL. In order for us to do the Texture Mapping with our
tabbed pages we needed to handle when the control's visiblity changed. So we
had overriden the OnVisbileChanged event.

Well it turns out that the Dispose() was getting called and completed but
then the OnVisibleChanged was called afterwards for the control. The wierd
thing about this is that the same order of methods were called on our laptops
(XP 32-bit) but we did not fall into the WindowsFormParkingEvent zombie
thread like we did on the x64 machines.

So I eneded up placing a conditional check to see if the OnVisibleChanged
even needed to be handled. Obviously in the Dispose I set the flag to false
so that OnVisibleChanged is not needed and this fixed it.

I hope this may help someone else in the future.
Regards,

Dennis
Feb 22 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by wukexin | last post: by
3 posts views Thread by Colin J. Williams | last post: by
7 posts views Thread by Corepaul | last post: by
5 posts views Thread by Steve | last post: by
8 posts views Thread by Mark | last post: by
1 post views Thread by XIAOLAOHU | last post: by
reply views Thread by MichaelMortimer | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.