Control MarshalingControl

Discussion in 'Microsoft VB .NET' started by Armin Zingler, Apr 7, 2011.

  1. Hi,

    as you don't like long descriptions: How can I avoid or control the
    creation of a MarshalingControl?

    Thanks!

    --
    Armin
     
    Armin Zingler, Apr 7, 2011
    #1
    1. Advertisements

  2. Armin Zingler

    Jason Keats Guest

    "Armin Zingler" <> wrote in message
    news:-berlin.de...
    > Hi,
    >
    > as you don't like long descriptions: How can I avoid or control the
    > creation of a MarshalingControl?


    As I don't like long answers:
    http://code.google.com/p/retlang/
     
    Jason Keats, Apr 8, 2011
    #2
    1. Advertisements

  3. Am 08.04.2011 05:14, schrieb Jason Keats:
    > "Armin Zingler" <> wrote in message
    > news:-berlin.de...
    >> Hi,
    >>
    >> as you don't like long descriptions: How can I avoid or control the
    >> creation of a MarshalingControl?

    >
    > As I don't like long answers:
    > http://code.google.com/p/retlang/


    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.


    --
    Armin
     
    Armin Zingler, Apr 8, 2011
    #3
  4. Armin Zingler

    Tom Shelton Guest

    Armin Zingler laid this down on his screen :
    > Am 08.04.2011 05:14, schrieb Jason Keats:
    >> "Armin Zingler" <> wrote in message
    >> news:-berlin.de...
    >>> Hi,
    >>>
    >>> as you don't like long descriptions: How can I avoid or control the
    >>> creation of a MarshalingControl?

    >>
    >> As I don't like long answers:
    >> http://code.google.com/p/retlang/

    >
    > 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.


    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?

    --
    Tom Shelton
     
    Tom Shelton, Apr 8, 2011
    #4
  5. Am 08.04.2011 20:30, schrieb Tom Shelton:
    > Armin Zingler laid this down on his screen :
    >> Am 08.04.2011 05:14, schrieb Jason Keats:
    >>> "Armin Zingler" <> wrote in message
    >>> news:-berlin.de...
    >>>> Hi,
    >>>>
    >>>> as you don't like long descriptions: How can I avoid or control the
    >>>> creation of a MarshalingControl?
    >>>
    >>> As I don't like long answers:
    >>> http://code.google.com/p/retlang/

    >>
    >> 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.

    >
    > 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?


    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.

    --
    Armin
     
    Armin Zingler, Apr 8, 2011
    #5
  6. Am 08.04.2011 22:16, schrieb Armin Zingler:
    >> 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?

    >
    > 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.


    I kept it as comprehensive and short as possible. I am unable to do better.



    --
    Armin
     
    Armin Zingler, Apr 12, 2011
    #6
  7. Armin Zingler

    Tom Shelton Guest

    Armin Zingler presented the following explanation :
    > Am 08.04.2011 22:16, schrieb Armin Zingler:
    >>> 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?

    >>
    >> 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.

    >
    > I kept it as comprehensive and short as possible. I am unable to do better.


    Hmmmm... I'm not seeing an obvious answer atm. I might have to play
    with this a bit - if I get time.

    --
    Tom Shelton
     
    Tom Shelton, Apr 12, 2011
    #7
  8. Armin Zingler, Apr 12, 2011
    #8
  9. Armin Zingler

    Jason Keats Guest

    Armin Zingler wrote:
    > 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.
    >


    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.
     
    Jason Keats, Apr 14, 2011
    #9
  10. Am 14.04.2011 16:22, schrieb Jason Keats:
    > Armin Zingler wrote:
    >> 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.
    >>

    >
    > 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/."


    > It's still impressively complicated, Armin.


    Why? Just start it, break, and switch to the thread named "TraceForm".

    > I put together a simpler version, that seems to work:
    > http://member.melbpc.org.au/~jkeats/files/FormTraceListener.zip


    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.

    > BTW, I still think retlang might provide a (better) solution. I just
    > haven't had time to prove it.


    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.

    --
    Armin
     
    Armin Zingler, Apr 14, 2011
    #10
  11. Armin Zingler

    Jason Keats Guest

    Armin Zingler wrote:
    > Am 14.04.2011 16:22, schrieb Jason Keats:
    >> Armin Zingler wrote:
    >>> 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.
    >>>

    >>
    >> 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/."
    >
    >
    >> It's still impressively complicated, Armin.

    >
    > Why? Just start it, break, and switch to the thread named "TraceForm".
    >
    >> I put together a simpler version, that seems to work:
    >> http://member.melbpc.org.au/~jkeats/files/FormTraceListener.zip

    >
    > 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.
    >
    >> BTW, I still think retlang might provide a (better) solution. I just
    >> haven't had time to prove it.

    >
    > 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.
     
    Jason Keats, Apr 15, 2011
    #11
  12. Am 15.04.2011 14:31, schrieb Jason Keats:
    > Good luck with finding a solution using your current methodology.


    Thanks anyway! I'll report if I find a solution.

    --
    Armin
     
    Armin Zingler, Apr 15, 2011
    #12
  13. Am 15.04.2011 19:02, schrieb Armin Zingler:
    > Am 15.04.2011 14:31, schrieb Jason Keats:
    >> Good luck with finding a solution using your current methodology.

    >
    > Thanks anyway! I'll report if I find a solution.


    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...

    --
    Armin
     
    Armin Zingler, Apr 16, 2011
    #13
  14. Am 16.04.2011 13:22, schrieb Armin Zingler:
    > I'll do so...


    Did so. Works.


    --
    Armin
     
    Armin Zingler, Apr 16, 2011
    #14
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Martin Horner

    Text Property on Multi- Control User Control

    Martin Horner, Sep 29, 2003, in forum: Microsoft VB .NET
    Replies:
    8
    Views:
    274
    Peter Huang [MSFT]
    Oct 2, 2003
  2. Matthew Louden
    Replies:
    1
    Views:
    401
    Scott M.
    Oct 11, 2003
  3. Tomas Oplt

    User control - remove control at runtime

    Tomas Oplt, Nov 20, 2003, in forum: Microsoft VB .NET
    Replies:
    1
    Views:
    395
    Herfried K. Wagner [MVP]
    Nov 20, 2003
  4. Sean

    Sizing a control on a multirowedTab Control

    Sean, Jan 7, 2004, in forum: Microsoft VB .NET
    Replies:
    2
    Views:
    124
  5. Guest
    Replies:
    0
    Views:
    397
    Guest
    Jan 22, 2004
Loading...

Share This Page