A
Armin Zingler
Hi,
as you don't like long descriptions: How can I avoid or control the
creation of a MarshalingControl?
Thanks!
as you don't like long descriptions: How can I avoid or control the
creation of a MarshalingControl?
Thanks!
J
Jason Keats
A
Armin Zingler
Am 08.04.2011 05:14, schrieb Jason Keats:
That's what I can expect from my question.
I thank you, though
I'm trying to elaborate a bit more:
My problem is that I got a dead-lock in my application running
two UI-threads independently. That means, I've payed great attention
to not creating a dead-lock in my own code. If you look at it, you'd
also be surprised that it can happen.
To be more specific, the line "New MyForm" does not return.
I do not do anything special in it. The window handle of the
Form is also not created inside because I do know that it
could cause a dead-lock. That's why *I* avoided it. However,
*the FW* internally creates a MarshallingControl and it's handle
inside "New MyForm". I'm a bit lost how to avoid this.
That's what I can expect from my question.
I thank you, thoughI'm trying to elaborate a bit more:
My problem is that I got a dead-lock in my application running
two UI-threads independently. That means, I've payed great attention
to not creating a dead-lock in my own code. If you look at it, you'd
also be surprised that it can happen.
To be more specific, the line "New MyForm" does not return.
I do not do anything special in it. The window handle of the
Form is also not created inside because I do know that it
could cause a dead-lock. That's why *I* avoided it. However,
*the FW* internally creates a MarshallingControl and it's handle
inside "New MyForm". I'm a bit lost how to avoid this.
T
Tom Shelton
Armin Zingler laid this down on his screen :
Armin - I'm having a bit of trouble following what your trying to
accomplish here... There shouldn't be an issue just creating forms on
different threads - is there some whay you could create a smallish
example that demonstrates your problem?
Am 08.04.2011 05:14, schrieb Jason Keats:
That's what I can expect from my question.
I'm trying to elaborate a bit more:
My problem is that I got a dead-lock in my application running
two UI-threads independently. That means, I've payed great attention
to not creating a dead-lock in my own code. If you look at it, you'd
also be surprised that it can happen.
To be more specific, the line "New MyForm" does not return.
I do not do anything special in it. The window handle of the
Form is also not created inside because I do know that it
could cause a dead-lock. That's why *I* avoided it. However,
*the FW* internally creates a MarshallingControl and it's handle
inside "New MyForm". I'm a bit lost how to avoid this.
Armin - I'm having a bit of trouble following what your trying to
accomplish here... There shouldn't be an issue just creating forms on
different threads - is there some whay you could create a smallish
example that demonstrates your problem?
A
Armin Zingler
Am 08.04.2011 20:30, schrieb Tom Shelton:
Thanks Tom for asking. Smallish is difficult. But I try to describe:
I wrote a TraceListener. It starts a new thread. The thread creates
a Form to display the output of the TraceListener. The TraceListener
must wait a short moment until the Form has been created:
Thread:
f_Form = New Traceform
FormCreatedEvent.Set
Listener:
FormCreatedEvent.WaitOne
WaitOne must be used carefully. I myself didn't put any blocking code into
"New Traceform", therefore it's ok here. I've put TraceListener+Form into
a Dll and have used it from several projects (successfully).
In my current project, I'm using the library, too. I put Debug.Writeline into
the WndProc of my startup Form. Result: Freeze at start-up. I found out that
the main thread is stuck in
CreateHandle -> WndProc -> Debug.Writeline -> TraceListener -> FormCreatedEvent.WaitOne
I wondered why WaitOne still waits because "New TraceForm" in the other thread
should be done in a millisecond. So, why does "New TraceForm" not return? The
callstack shows:
New TraceForm -> .... -> New MarshalingControl -> MarshalingControl.Creathandle
Conclusion: While the main thread is inside CreateHandle waiting for the
Form in the other thread being created, that thread is also inside
CreateHandle trying to create the MarshalingControl. The FW synchronizes
simultaneous creation of window handles from different threads. That's ok,
and I don't do it myself, but due to that MarshalingControl which is out
of my own scope of responsibility, the dead-lock occurs.
Thanks Tom for asking. Smallish is difficult. But I try to describe:
I wrote a TraceListener. It starts a new thread. The thread creates
a Form to display the output of the TraceListener. The TraceListener
must wait a short moment until the Form has been created:
Thread:
f_Form = New Traceform
FormCreatedEvent.Set
Listener:
FormCreatedEvent.WaitOne
WaitOne must be used carefully. I myself didn't put any blocking code into
"New Traceform", therefore it's ok here. I've put TraceListener+Form into
a Dll and have used it from several projects (successfully).
In my current project, I'm using the library, too. I put Debug.Writeline into
the WndProc of my startup Form. Result: Freeze at start-up. I found out that
the main thread is stuck in
CreateHandle -> WndProc -> Debug.Writeline -> TraceListener -> FormCreatedEvent.WaitOne
I wondered why WaitOne still waits because "New TraceForm" in the other thread
should be done in a millisecond. So, why does "New TraceForm" not return? The
callstack shows:
New TraceForm -> .... -> New MarshalingControl -> MarshalingControl.Creathandle
Conclusion: While the main thread is inside CreateHandle waiting for the
Form in the other thread being created, that thread is also inside
CreateHandle trying to create the MarshalingControl. The FW synchronizes
simultaneous creation of window handles from different threads. That's ok,
and I don't do it myself, but due to that MarshalingControl which is out
of my own scope of responsibility, the dead-lock occurs.
A
Armin Zingler
Am 08.04.2011 22:16, schrieb Armin Zingler:
I kept it as comprehensive and short as possible. I am unable to do better.
I kept it as comprehensive and short as possible. I am unable to do better.
T
Tom Shelton
Armin Zingler presented the following explanation :
Hmmmm... I'm not seeing an obvious answer atm. I might have to play
with this a bit - if I get time.
Hmmmm... I'm not seeing an obvious answer atm. I might have to play
with this a bit - if I get time.
A
Armin Zingler
Hi,
project to reproduce:
http://www.file-upload.net/download-3354148/DemoMarshalingControl.zip.html
Please note that some code has been copied and pasted
from several sources to make it work.
project to reproduce:
http://www.file-upload.net/download-3354148/DemoMarshalingControl.zip.html
Please note that some code has been copied and pasted
from several sources to make it work.
J
Jason Keats
Armin said:
I think you mean that you've copied and pasted the minimum code required
to show it doesn't work.
It's still impressively complicated, Armin.
I put together a simpler version, that seems to work:
http://member.melbpc.org.au/~jkeats/files/FormTraceListener.zip
BTW, I still think retlang might provide a (better) solution. I just
haven't had time to prove it.
A
Armin Zingler
Am 14.04.2011 16:22, schrieb Jason Keats:
I meant: "...to make it /compile/."
Why? Just start it, break, and switch to the thread named "TraceForm".
Jason, thanks a lot for taking the time. However, I am talking about a
multi-threading issue. You do not start a new thread in your project,
so I don't see the relation to my problem.
I haven't looked at it yet. Actually I'm interested if I did anything wrong.
I'm pretty sure I did not - though it doesn't work.
I think you mean that you've copied and pasted the minimum code required
to show it doesn't work.
I meant: "...to make it /compile/."
Why? Just start it, break, and switch to the thread named "TraceForm".
Jason, thanks a lot for taking the time. However, I am talking about a
multi-threading issue. You do not start a new thread in your project,
so I don't see the relation to my problem.
I haven't looked at it yet. Actually I'm interested if I did anything wrong.
I'm pretty sure I did not - though it doesn't work.
J
Jason Keats
Armin said:Am 14.04.2011 16:22, schrieb Jason Keats:
I meant: "...to make it /compile/."
Why? Just start it, break, and switch to the thread named "TraceForm".
Jason, thanks a lot for taking the time. However, I am talking about a
multi-threading issue. You do not start a new thread in your project,
so I don't see the relation to my problem.
I haven't looked at it yet. Actually I'm interested if I did anything wrong.
I'm pretty sure I did not - though it doesn't work.
I think that anything that uses the ".NET way" of threading is
complicated. Your problem proves it. That's why I suggested trying the
pub/sub method used by retlang. Unfortunately, it's a .NET 4.0 library.
Therefore, as I believe you're using VS2008, you're out of luck.
As I wasn't sure whether you were after a working program or just had a
theoretical interest in your particular error, I provided my little
experiment in trace listeners - in case it was useful. I'm not surprised
that it wasn't. ;-)
I have found tracing helpful in ASP.NET development, but haven't used it
with Windows Forms. I can see how a DLL that immediately displays
diagnostic information via a Form could be useful.
Good luck with finding a solution using your current methodology.
A
Armin Zingler
Am 15.04.2011 14:31, schrieb Jason Keats:
Thanks anyway! I'll report if I find a solution.
Thanks anyway! I'll report if I find a solution.
A
Armin Zingler
Am 15.04.2011 19:02, schrieb Armin Zingler:
One approach that I've thought of but wanted to avoid if there's
another solution is moving the message buffer from the Form to the
TraceListener itself. This way, the TraceListener does not have
to wait for the Form to be created.
I'll do so...
One approach that I've thought of but wanted to avoid if there's
another solution is moving the message buffer from the Form to the
TraceListener itself. This way, the TraceListener does not have
to wait for the Form to be created.
I'll do so...
A
Armin Zingler
Am 16.04.2011 13:22, schrieb Armin Zingler:
Did so. Works.
Did so. Works.