[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Patrick Jox

9/29/2004 10:06:00 AM

Hi,
I have some problems with eventhandlers, that update some gui elements. I
have implemented an eventwrapper class, that exposes an event handler which
is registered to the server.event. This eventhandler then fires another
event to which a gui method is registered. As long as I am using tcp, my gui
hangs. I tried around with several ideas but I always had the same result. I
got an example that did exactly the same as my application and it worked
fine ther. The only difference was, that I was using tcp and the example was
using http.

So in a moment of crazyness i switched my application to http and since than
it worked.

Can anybody explain this behavior?

I thought, that the protocoll should not influence my implementation so
deep?

Any Ideas?

Thanks - Patrick


9 Answers

Ken Kolda

9/29/2004 4:04:00 PM

0

The most likely source of your problem is that you're not using the
Form.Invoke() method to marshal the call to your UI thread before changing
your GUI. The callback into your client will never occur on the UI thread,
so these calls should never directly modify UI elements in a form. Even if
this seems to work for HTTP, you still need to use Form.Invoke() -- that's
the only guaranteed safe method.

Ken


"Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote in
message news:%230e%235xgpEHA.2864@TK2MSFTNGP12.phx.gbl...
> Hi,
> I have some problems with eventhandlers, that update some gui elements. I
> have implemented an eventwrapper class, that exposes an event handler
which
> is registered to the server.event. This eventhandler then fires another
> event to which a gui method is registered. As long as I am using tcp, my
gui
> hangs. I tried around with several ideas but I always had the same result.
I
> got an example that did exactly the same as my application and it worked
> fine ther. The only difference was, that I was using tcp and the example
was
> using http.
>
> So in a moment of crazyness i switched my application to http and since
than
> it worked.
>
> Can anybody explain this behavior?
>
> I thought, that the protocoll should not influence my implementation so
> deep?
>
> Any Ideas?
>
> Thanks - Patrick
>
>


Patrick Jox

9/30/2004 4:53:00 AM

0

Hi Ken,
thanks again for trying to help me. The application where I am working
around is still the same.

I tried to do the following with tcp.

I wrote an eventhandler, named eventwrapper. He was instanced by the form by
passing the form itself and a forms delegate to the constructor.
The eventhandler provided an event procedure. This procedure was registered
to listening events of my server. When the event occured he executed
something like form.Invoke(formsDelegate).

But as soon as the delegate tried to modify GUI elements. The application
hang?

What is wrong with that. Do you know an example for managing this.

Thanks - Patrick



"Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im Newsbeitrag
news:uVh053jpEHA.3428@TK2MSFTNGP11.phx.gbl...
> The most likely source of your problem is that you're not using the
> Form.Invoke() method to marshal the call to your UI thread before changing
> your GUI. The callback into your client will never occur on the UI thread,
> so these calls should never directly modify UI elements in a form. Even if
> this seems to work for HTTP, you still need to use Form.Invoke() -- that's
> the only guaranteed safe method.
>
> Ken
>
>
> "Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote in
> message news:%230e%235xgpEHA.2864@TK2MSFTNGP12.phx.gbl...
> > Hi,
> > I have some problems with eventhandlers, that update some gui elements.
I
> > have implemented an eventwrapper class, that exposes an event handler
> which
> > is registered to the server.event. This eventhandler then fires another
> > event to which a gui method is registered. As long as I am using tcp, my
> gui
> > hangs. I tried around with several ideas but I always had the same
result.
> I
> > got an example that did exactly the same as my application and it worked
> > fine ther. The only difference was, that I was using tcp and the example
> was
> > using http.
> >
> > So in a moment of crazyness i switched my application to http and since
> than
> > it worked.
> >
> > Can anybody explain this behavior?
> >
> > I thought, that the protocoll should not influence my implementation so
> > deep?
> >
> > Any Ideas?
> >
> > Thanks - Patrick
> >
> >
>
>


Ryan Berry

9/30/2004 2:09:00 PM

0

Patrick,

I'm not sure I follow what you tried to do with "tcp". What Ken is
saying is that you should not modify GUI elements from any other thread
than the main GUI thread; thus, you need to use form.invoke. Here's an
example: (I used 2 parameters to show how to use the object array)

Delegate Definition:
private delegate void EventCompleteCB(string Message,in Value);

Event Delegate: (IE: Method that is calledback on when the event is
raised)
private void EventComplete(string Message, int Value)
{
Object[] param = {Message,Value};
this.Invoke(new EventCompleteCB(InternalEventComplete),param);
}

Internal Form GUI Update Method:
private void InternalEventComplete(string Message, int Value)
{
// Only update GUI elements here
[formControl].Text = Message;
}

Hope this helps.

-- Ryan Berry

Ken Kolda

9/30/2004 3:20:00 PM

0

That certainly sounds reasonable -- if your wrapper is calling Form.Invoke()
then you should be good. If you can post a very simple project that
demonstrates this problem, that might be helpful.

Ken


"Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote in
message news:Orxd7nqpEHA.324@TK2MSFTNGP11.phx.gbl...
> Hi Ken,
> thanks again for trying to help me. The application where I am working
> around is still the same.
>
> I tried to do the following with tcp.
>
> I wrote an eventhandler, named eventwrapper. He was instanced by the form
by
> passing the form itself and a forms delegate to the constructor.
> The eventhandler provided an event procedure. This procedure was
registered
> to listening events of my server. When the event occured he executed
> something like form.Invoke(formsDelegate).
>
> But as soon as the delegate tried to modify GUI elements. The application
> hang?
>
> What is wrong with that. Do you know an example for managing this.
>
> Thanks - Patrick
>
>
>
> "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im Newsbeitrag
> news:uVh053jpEHA.3428@TK2MSFTNGP11.phx.gbl...
> > The most likely source of your problem is that you're not using the
> > Form.Invoke() method to marshal the call to your UI thread before
changing
> > your GUI. The callback into your client will never occur on the UI
thread,
> > so these calls should never directly modify UI elements in a form. Even
if
> > this seems to work for HTTP, you still need to use Form.Invoke() --
that's
> > the only guaranteed safe method.
> >
> > Ken
> >
> >
> > "Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote in
> > message news:%230e%235xgpEHA.2864@TK2MSFTNGP12.phx.gbl...
> > > Hi,
> > > I have some problems with eventhandlers, that update some gui
elements.
> I
> > > have implemented an eventwrapper class, that exposes an event handler
> > which
> > > is registered to the server.event. This eventhandler then fires
another
> > > event to which a gui method is registered. As long as I am using tcp,
my
> > gui
> > > hangs. I tried around with several ideas but I always had the same
> result.
> > I
> > > got an example that did exactly the same as my application and it
worked
> > > fine ther. The only difference was, that I was using tcp and the
example
> > was
> > > using http.
> > >
> > > So in a moment of crazyness i switched my application to http and
since
> > than
> > > it worked.
> > >
> > > Can anybody explain this behavior?
> > >
> > > I thought, that the protocoll should not influence my implementation
so
> > > deep?
> > >
> > > Any Ideas?
> > >
> > > Thanks - Patrick
> > >
> > >
> >
> >
>
>


Ken Kolda

10/1/2004 3:10:00 PM

0

This project won't compile -- looks like it's missing a Chat.Shared assembly
that contains object definitions needed by the projects.

Ken


"Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote in
message news:%23T%23V$J8pEHA.3464@TK2MSFTNGP14.phx.gbl...
> Hi Ken,
> here is my good old AddressManager Project, where I implemented the
invoking
> code.
>
> Hope you can see, what i am blind for :-))
>
> Patrick
>
> "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im Newsbeitrag
> news:%23a2v8DwpEHA.2696@TK2MSFTNGP15.phx.gbl...
> > That certainly sounds reasonable -- if your wrapper is calling
> Form.Invoke()
> > then you should be good. If you can post a very simple project that
> > demonstrates this problem, that might be helpful.
> >
> > Ken
> >
> >
> > "Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote in
> > message news:Orxd7nqpEHA.324@TK2MSFTNGP11.phx.gbl...
> > > Hi Ken,
> > > thanks again for trying to help me. The application where I am working
> > > around is still the same.
> > >
> > > I tried to do the following with tcp.
> > >
> > > I wrote an eventhandler, named eventwrapper. He was instanced by the
> form
> > by
> > > passing the form itself and a forms delegate to the constructor.
> > > The eventhandler provided an event procedure. This procedure was
> > registered
> > > to listening events of my server. When the event occured he executed
> > > something like form.Invoke(formsDelegate).
> > >
> > > But as soon as the delegate tried to modify GUI elements. The
> application
> > > hang?
> > >
> > > What is wrong with that. Do you know an example for managing this.
> > >
> > > Thanks - Patrick
> > >
> > >
> > >
> > > "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im
Newsbeitrag
> > > news:uVh053jpEHA.3428@TK2MSFTNGP11.phx.gbl...
> > > > The most likely source of your problem is that you're not using the
> > > > Form.Invoke() method to marshal the call to your UI thread before
> > changing
> > > > your GUI. The callback into your client will never occur on the UI
> > thread,
> > > > so these calls should never directly modify UI elements in a form.
> Even
> > if
> > > > this seems to work for HTTP, you still need to use Form.Invoke() --
> > that's
> > > > the only guaranteed safe method.
> > > >
> > > > Ken
> > > >
> > > >
> > > > "Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote
in
> > > > message news:%230e%235xgpEHA.2864@TK2MSFTNGP12.phx.gbl...
> > > > > Hi,
> > > > > I have some problems with eventhandlers, that update some gui
> > elements.
> > > I
> > > > > have implemented an eventwrapper class, that exposes an event
> handler
> > > > which
> > > > > is registered to the server.event. This eventhandler then fires
> > another
> > > > > event to which a gui method is registered. As long as I am using
> tcp,
> > my
> > > > gui
> > > > > hangs. I tried around with several ideas but I always had the same
> > > result.
> > > > I
> > > > > got an example that did exactly the same as my application and it
> > worked
> > > > > fine ther. The only difference was, that I was using tcp and the
> > example
> > > > was
> > > > > using http.
> > > > >
> > > > > So in a moment of crazyness i switched my application to http and
> > since
> > > > than
> > > > > it worked.
> > > > >
> > > > > Can anybody explain this behavior?
> > > > >
> > > > > I thought, that the protocoll should not influence my
implementation
> > so
> > > > > deep?
> > > > >
> > > > > Any Ideas?
> > > > >
> > > > > Thanks - Patrick
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
>


Ken Kolda

10/1/2004 3:18:00 PM

0

Although it wouldn't compile, I read through what you have. Here's where you
create your event handler using the wrapper class:

Delegator = new DisplayEvent(this._wrapper_MessageArrived);
eventWrapperWithDelegate = new Chat.Shared.EventWrapperWithDelegate(this,
Delegator);
am.MessageArrived += new
Chat.Shared.MessageArrivedEventHandler(eventWrapperWithDelegate.EventCatched
);

So I then checked out the definition for your callback method
_wrapper_MessageArrived():

public void _wrapper_MessageArrived(object sender,
Chat.Shared.MessageArrivedEventArgs e)
{
textBoxOutput.Text += e.Message + "\r\n";
}

This code is modifying the UI but I don't see any call to Form.Invoke() in
the entire project -- am I missing something?? The correct version using
Form.Invoke would look something like:

public void _wrapper_MessageArrived(object sender,
Chat.Shared.MessageArrivedEventArgs e)
{
if (this.InvokeRequried)
this.Invoke(new WaitDelegate(updateOutput), new object[] {
e.Message });
else
updateOutput(e.Message);
}

public void updateOutput(object text)
{
textBoxOutput.Text += text + "\r\n";
}

When you said that form.Invoke() was being called, where is this in the
code??

Ken

"Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote in
message news:%23T%23V$J8pEHA.3464@TK2MSFTNGP14.phx.gbl...
> Hi Ken,
> here is my good old AddressManager Project, where I implemented the
invoking
> code.
>
> Hope you can see, what i am blind for :-))
>
> Patrick
>
> "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im Newsbeitrag
> news:%23a2v8DwpEHA.2696@TK2MSFTNGP15.phx.gbl...
> > That certainly sounds reasonable -- if your wrapper is calling
> Form.Invoke()
> > then you should be good. If you can post a very simple project that
> > demonstrates this problem, that might be helpful.
> >
> > Ken
> >
> >
> > "Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote in
> > message news:Orxd7nqpEHA.324@TK2MSFTNGP11.phx.gbl...
> > > Hi Ken,
> > > thanks again for trying to help me. The application where I am working
> > > around is still the same.
> > >
> > > I tried to do the following with tcp.
> > >
> > > I wrote an eventhandler, named eventwrapper. He was instanced by the
> form
> > by
> > > passing the form itself and a forms delegate to the constructor.
> > > The eventhandler provided an event procedure. This procedure was
> > registered
> > > to listening events of my server. When the event occured he executed
> > > something like form.Invoke(formsDelegate).
> > >
> > > But as soon as the delegate tried to modify GUI elements. The
> application
> > > hang?
> > >
> > > What is wrong with that. Do you know an example for managing this.
> > >
> > > Thanks - Patrick
> > >
> > >
> > >
> > > "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im
Newsbeitrag
> > > news:uVh053jpEHA.3428@TK2MSFTNGP11.phx.gbl...
> > > > The most likely source of your problem is that you're not using the
> > > > Form.Invoke() method to marshal the call to your UI thread before
> > changing
> > > > your GUI. The callback into your client will never occur on the UI
> > thread,
> > > > so these calls should never directly modify UI elements in a form.
> Even
> > if
> > > > this seems to work for HTTP, you still need to use Form.Invoke() --
> > that's
> > > > the only guaranteed safe method.
> > > >
> > > > Ken
> > > >
> > > >
> > > > "Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote
in
> > > > message news:%230e%235xgpEHA.2864@TK2MSFTNGP12.phx.gbl...
> > > > > Hi,
> > > > > I have some problems with eventhandlers, that update some gui
> > elements.
> > > I
> > > > > have implemented an eventwrapper class, that exposes an event
> handler
> > > > which
> > > > > is registered to the server.event. This eventhandler then fires
> > another
> > > > > event to which a gui method is registered. As long as I am using
> tcp,
> > my
> > > > gui
> > > > > hangs. I tried around with several ideas but I always had the same
> > > result.
> > > > I
> > > > > got an example that did exactly the same as my application and it
> > worked
> > > > > fine ther. The only difference was, that I was using tcp and the
> > example
> > > > was
> > > > > using http.
> > > > >
> > > > > So in a moment of crazyness i switched my application to http and
> > since
> > > > than
> > > > > it worked.
> > > > >
> > > > > Can anybody explain this behavior?
> > > > >
> > > > > I thought, that the protocoll should not influence my
implementation
> > so
> > > > > deep?
> > > > >
> > > > > Any Ideas?
> > > > >
> > > > > Thanks - Patrick
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
>


Ken Kolda

10/1/2004 8:12:00 PM

0

Ahhh.. should have thought of this before. Your call to your server is
occuring on the UI thread of the client. It blocks while waiting for the
server's response. While the server's processing the response, it calls back
to your client (on a non-UI thread). This thread uses Form.Invoke() to
marshal the call to the UI thread (which is still blocked waiting for a
response to the server). So, you've got deadlock.

To work around this, use Form.BeginInvoke() instead of Form.Invoke(). This
will allow the callback thread to complete its processing without waiting on
the UI thread.

Ken


"Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote in
message news:%23LFuWQ%23pEHA.896@TK2MSFTNGP12.phx.gbl...
> Hi Ken,
> sorry for this inconvenience. My solution pointed to a directory that was
> not in the zipped struktur. Now it should compile.
>
> The form.Invoke is called in the fileEventWrapperWithDelegate.cs
>
> Sorry again.- Patrick
> "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im Newsbeitrag
> news:%2300NYj8pEHA.3868@TK2MSFTNGP15.phx.gbl...
> > This project won't compile -- looks like it's missing a Chat.Shared
> assembly
> > that contains object definitions needed by the projects.
> >
> > Ken
> >
> >
> > "Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote in
> > message news:%23T%23V$J8pEHA.3464@TK2MSFTNGP14.phx.gbl...
> > > Hi Ken,
> > > here is my good old AddressManager Project, where I implemented the
> > invoking
> > > code.
> > >
> > > Hope you can see, what i am blind for :-))
> > >
> > > Patrick
> > >
> > > "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im
Newsbeitrag
> > > news:%23a2v8DwpEHA.2696@TK2MSFTNGP15.phx.gbl...
> > > > That certainly sounds reasonable -- if your wrapper is calling
> > > Form.Invoke()
> > > > then you should be good. If you can post a very simple project that
> > > > demonstrates this problem, that might be helpful.
> > > >
> > > > Ken
> > > >
> > > >
> > > > "Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote
in
> > > > message news:Orxd7nqpEHA.324@TK2MSFTNGP11.phx.gbl...
> > > > > Hi Ken,
> > > > > thanks again for trying to help me. The application where I am
> working
> > > > > around is still the same.
> > > > >
> > > > > I tried to do the following with tcp.
> > > > >
> > > > > I wrote an eventhandler, named eventwrapper. He was instanced by
the
> > > form
> > > > by
> > > > > passing the form itself and a forms delegate to the constructor.
> > > > > The eventhandler provided an event procedure. This procedure was
> > > > registered
> > > > > to listening events of my server. When the event occured he
executed
> > > > > something like form.Invoke(formsDelegate).
> > > > >
> > > > > But as soon as the delegate tried to modify GUI elements. The
> > > application
> > > > > hang?
> > > > >
> > > > > What is wrong with that. Do you know an example for managing this.
> > > > >
> > > > > Thanks - Patrick
> > > > >
> > > > >
> > > > >
> > > > > "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im
> > Newsbeitrag
> > > > > news:uVh053jpEHA.3428@TK2MSFTNGP11.phx.gbl...
> > > > > > The most likely source of your problem is that you're not using
> the
> > > > > > Form.Invoke() method to marshal the call to your UI thread
before
> > > > changing
> > > > > > your GUI. The callback into your client will never occur on the
UI
> > > > thread,
> > > > > > so these calls should never directly modify UI elements in a
form.
> > > Even
> > > > if
> > > > > > this seems to work for HTTP, you still need to use
> Form.Invoke() --
> > > > that's
> > > > > > the only guaranteed safe method.
> > > > > >
> > > > > > Ken
> > > > > >
> > > > > >
> > > > > > "Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com>
> wrote
> > in
> > > > > > message news:%230e%235xgpEHA.2864@TK2MSFTNGP12.phx.gbl...
> > > > > > > Hi,
> > > > > > > I have some problems with eventhandlers, that update some gui
> > > > elements.
> > > > > I
> > > > > > > have implemented an eventwrapper class, that exposes an event
> > > handler
> > > > > > which
> > > > > > > is registered to the server.event. This eventhandler then
fires
> > > > another
> > > > > > > event to which a gui method is registered. As long as I am
using
> > > tcp,
> > > > my
> > > > > > gui
> > > > > > > hangs. I tried around with several ideas but I always had the
> same
> > > > > result.
> > > > > > I
> > > > > > > got an example that did exactly the same as my application and
> it
> > > > worked
> > > > > > > fine ther. The only difference was, that I was using tcp and
the
> > > > example
> > > > > > was
> > > > > > > using http.
> > > > > > >
> > > > > > > So in a moment of crazyness i switched my application to http
> and
> > > > since
> > > > > > than
> > > > > > > it worked.
> > > > > > >
> > > > > > > Can anybody explain this behavior?
> > > > > > >
> > > > > > > I thought, that the protocoll should not influence my
> > implementation
> > > > so
> > > > > > > deep?
> > > > > > >
> > > > > > > Any Ideas?
> > > > > > >
> > > > > > > Thanks - Patrick
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>
>


Patrick Jox

10/2/2004 9:43:00 AM

0

Hmm, this seems to bee much better. At least the UI-Thread does not stop but
I get the following excption:
"The Type System.Windows.Forms.Control+ThreadMethodEntry in Assembly
System.Windows.Forms, Version=1.0.5000.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089 is not marked as serializable."

The following line does not help.

[Serializable]

public delegate void DisplayEvent(object sender,
Chat.Shared.MessageArrivedEventArgs e);

:-( - Patrick

"Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im Newsbeitrag
news:%23SwE$L$pEHA.348@TK2MSFTNGP15.phx.gbl...
> Ahhh.. should have thought of this before. Your call to your server is
> occuring on the UI thread of the client. It blocks while waiting for the
> server's response. While the server's processing the response, it calls
back
> to your client (on a non-UI thread). This thread uses Form.Invoke() to
> marshal the call to the UI thread (which is still blocked waiting for a
> response to the server). So, you've got deadlock.
>
> To work around this, use Form.BeginInvoke() instead of Form.Invoke(). This
> will allow the callback thread to complete its processing without waiting
on
> the UI thread.
>
> Ken
>
>
> "Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote in
> message news:%23LFuWQ%23pEHA.896@TK2MSFTNGP12.phx.gbl...
> > Hi Ken,
> > sorry for this inconvenience. My solution pointed to a directory that
was
> > not in the zipped struktur. Now it should compile.
> >
> > The form.Invoke is called in the fileEventWrapperWithDelegate.cs
> >
> > Sorry again.- Patrick
> > "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im Newsbeitrag
> > news:%2300NYj8pEHA.3868@TK2MSFTNGP15.phx.gbl...
> > > This project won't compile -- looks like it's missing a Chat.Shared
> > assembly
> > > that contains object definitions needed by the projects.
> > >
> > > Ken
> > >
> > >
> > > "Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote in
> > > message news:%23T%23V$J8pEHA.3464@TK2MSFTNGP14.phx.gbl...
> > > > Hi Ken,
> > > > here is my good old AddressManager Project, where I implemented the
> > > invoking
> > > > code.
> > > >
> > > > Hope you can see, what i am blind for :-))
> > > >
> > > > Patrick
> > > >
> > > > "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im
> Newsbeitrag
> > > > news:%23a2v8DwpEHA.2696@TK2MSFTNGP15.phx.gbl...
> > > > > That certainly sounds reasonable -- if your wrapper is calling
> > > > Form.Invoke()
> > > > > then you should be good. If you can post a very simple project
that
> > > > > demonstrates this problem, that might be helpful.
> > > > >
> > > > > Ken
> > > > >
> > > > >
> > > > > "Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com>
wrote
> in
> > > > > message news:Orxd7nqpEHA.324@TK2MSFTNGP11.phx.gbl...
> > > > > > Hi Ken,
> > > > > > thanks again for trying to help me. The application where I am
> > working
> > > > > > around is still the same.
> > > > > >
> > > > > > I tried to do the following with tcp.
> > > > > >
> > > > > > I wrote an eventhandler, named eventwrapper. He was instanced by
> the
> > > > form
> > > > > by
> > > > > > passing the form itself and a forms delegate to the constructor.
> > > > > > The eventhandler provided an event procedure. This procedure was
> > > > > registered
> > > > > > to listening events of my server. When the event occured he
> executed
> > > > > > something like form.Invoke(formsDelegate).
> > > > > >
> > > > > > But as soon as the delegate tried to modify GUI elements. The
> > > > application
> > > > > > hang?
> > > > > >
> > > > > > What is wrong with that. Do you know an example for managing
this.
> > > > > >
> > > > > > Thanks - Patrick
> > > > > >
> > > > > >
> > > > > >
> > > > > > "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im
> > > Newsbeitrag
> > > > > > news:uVh053jpEHA.3428@TK2MSFTNGP11.phx.gbl...
> > > > > > > The most likely source of your problem is that you're not
using
> > the
> > > > > > > Form.Invoke() method to marshal the call to your UI thread
> before
> > > > > changing
> > > > > > > your GUI. The callback into your client will never occur on
the
> UI
> > > > > thread,
> > > > > > > so these calls should never directly modify UI elements in a
> form.
> > > > Even
> > > > > if
> > > > > > > this seems to work for HTTP, you still need to use
> > Form.Invoke() --
> > > > > that's
> > > > > > > the only guaranteed safe method.
> > > > > > >
> > > > > > > Ken
> > > > > > >
> > > > > > >
> > > > > > > "Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com>
> > wrote
> > > in
> > > > > > > message news:%230e%235xgpEHA.2864@TK2MSFTNGP12.phx.gbl...
> > > > > > > > Hi,
> > > > > > > > I have some problems with eventhandlers, that update some
gui
> > > > > elements.
> > > > > > I
> > > > > > > > have implemented an eventwrapper class, that exposes an
event
> > > > handler
> > > > > > > which
> > > > > > > > is registered to the server.event. This eventhandler then
> fires
> > > > > another
> > > > > > > > event to which a gui method is registered. As long as I am
> using
> > > > tcp,
> > > > > my
> > > > > > > gui
> > > > > > > > hangs. I tried around with several ideas but I always had
the
> > same
> > > > > > result.
> > > > > > > I
> > > > > > > > got an example that did exactly the same as my application
and
> > it
> > > > > worked
> > > > > > > > fine ther. The only difference was, that I was using tcp and
> the
> > > > > example
> > > > > > > was
> > > > > > > > using http.
> > > > > > > >
> > > > > > > > So in a moment of crazyness i switched my application to
http
> > and
> > > > > since
> > > > > > > than
> > > > > > > > it worked.
> > > > > > > >
> > > > > > > > Can anybody explain this behavior?
> > > > > > > >
> > > > > > > > I thought, that the protocoll should not influence my
> > > implementation
> > > > > so
> > > > > > > > deep?
> > > > > > > >
> > > > > > > > Any Ideas?
> > > > > > > >
> > > > > > > > Thanks - Patrick
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>


Patrick Jox

10/2/2004 12:14:00 PM

0

Hi Ken,
I tried your Solution from yesterday. The following works fine now either
with http and with tcp. And I think it is a proper solution now thanks to
you ;-))

In my BusinessTier I catch the Event with an Wrapper which does nothing else
than repeat the event (so its more a Repeater than a Wrapper)
public delegate void LogEntryCreatedEventHandler(object sender,
LogEntryCreatedEventArgs e);

public class LogEntryCreatedListener:MarshalByRefObject

{

public event LogEntryCreatedEventHandler LogEntryCreated;

public void OnLogEntryCreated(object sender, LogEntryCreatedEventArgs e)

{

if (LogEntryCreated != null)

{

LogEntryCreated(sender, e);

}

}

public override object InitializeLifetimeService()

{

return null;

}

}

In the form I declare a socalled WaitDelegate as

public delegate void WaitDelegate(object obj);

and the following code to treat the event.

private void LogEntry_OnCreate(object sender,
BaseControl.Shared.LogEntryCreatedEventArgs e)

{

if (this.InvokeRequired)

this.BeginInvoke(new WaitDelegate(updateOutput), new object[] {e.Message });

else

updateOutput(e.Message);

}

public void updateOutput(object text)

{

textBoxOutputMain.Text += text + "\r\n";

}

The eventlistener is registered as follows:

bcApp = new softwerk.Core.App.Application();

Console.WriteLine("Connecting {0}", bcApp.Name);

LoggingListener= new softwerk.Shared.LogEntryCreatedListener();

LoggingListener.LogEntryCreated += new
softwerk.Shared.LogEntryCreatedEventHandler(LogEntry_OnCreate);

bcApp.Logger.LogEntryCreated +=new
softwerkl.Shared.LogEntryCreatedEventHandler(LoggingListener.OnLogEntryCreat
ed);

Now it works and I am happy for the weekend.

Thank you very much - Patrick



"Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> schrieb im
Newsbeitrag news:eoBdZTGqEHA.800@TK2MSFTNGP14.phx.gbl...
> Hmm, this seems to bee much better. At least the UI-Thread does not stop
but
> I get the following excption:
> "The Type System.Windows.Forms.Control+ThreadMethodEntry in Assembly
> System.Windows.Forms, Version=1.0.5000.0, Culture=neutral,
> PublicKeyToken=b77a5c561934e089 is not marked as serializable."
>
> The following line does not help.
>
> [Serializable]
>
> public delegate void DisplayEvent(object sender,
> Chat.Shared.MessageArrivedEventArgs e);
>
> :-( - Patrick
>
> "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im Newsbeitrag
> news:%23SwE$L$pEHA.348@TK2MSFTNGP15.phx.gbl...
> > Ahhh.. should have thought of this before. Your call to your server is
> > occuring on the UI thread of the client. It blocks while waiting for the
> > server's response. While the server's processing the response, it calls
> back
> > to your client (on a non-UI thread). This thread uses Form.Invoke() to
> > marshal the call to the UI thread (which is still blocked waiting for a
> > response to the server). So, you've got deadlock.
> >
> > To work around this, use Form.BeginInvoke() instead of Form.Invoke().
This
> > will allow the callback thread to complete its processing without
waiting
> on
> > the UI thread.
> >
> > Ken
> >
> >
> > "Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote in
> > message news:%23LFuWQ%23pEHA.896@TK2MSFTNGP12.phx.gbl...
> > > Hi Ken,
> > > sorry for this inconvenience. My solution pointed to a directory that
> was
> > > not in the zipped struktur. Now it should compile.
> > >
> > > The form.Invoke is called in the fileEventWrapperWithDelegate.cs
> > >
> > > Sorry again.- Patrick
> > > "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im
Newsbeitrag
> > > news:%2300NYj8pEHA.3868@TK2MSFTNGP15.phx.gbl...
> > > > This project won't compile -- looks like it's missing a Chat.Shared
> > > assembly
> > > > that contains object definitions needed by the projects.
> > > >
> > > > Ken
> > > >
> > > >
> > > > "Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com> wrote
in
> > > > message news:%23T%23V$J8pEHA.3464@TK2MSFTNGP14.phx.gbl...
> > > > > Hi Ken,
> > > > > here is my good old AddressManager Project, where I implemented
the
> > > > invoking
> > > > > code.
> > > > >
> > > > > Hope you can see, what i am blind for :-))
> > > > >
> > > > > Patrick
> > > > >
> > > > > "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im
> > Newsbeitrag
> > > > > news:%23a2v8DwpEHA.2696@TK2MSFTNGP15.phx.gbl...
> > > > > > That certainly sounds reasonable -- if your wrapper is calling
> > > > > Form.Invoke()
> > > > > > then you should be good. If you can post a very simple project
> that
> > > > > > demonstrates this problem, that might be helpful.
> > > > > >
> > > > > > Ken
> > > > > >
> > > > > >
> > > > > > "Patrick Jox" <Patrick@softwerk-n-o-s-p-a-m-technologies.com>
> wrote
> > in
> > > > > > message news:Orxd7nqpEHA.324@TK2MSFTNGP11.phx.gbl...
> > > > > > > Hi Ken,
> > > > > > > thanks again for trying to help me. The application where I am
> > > working
> > > > > > > around is still the same.
> > > > > > >
> > > > > > > I tried to do the following with tcp.
> > > > > > >
> > > > > > > I wrote an eventhandler, named eventwrapper. He was instanced
by
> > the
> > > > > form
> > > > > > by
> > > > > > > passing the form itself and a forms delegate to the
constructor.
> > > > > > > The eventhandler provided an event procedure. This procedure
was
> > > > > > registered
> > > > > > > to listening events of my server. When the event occured he
> > executed
> > > > > > > something like form.Invoke(formsDelegate).
> > > > > > >
> > > > > > > But as soon as the delegate tried to modify GUI elements. The
> > > > > application
> > > > > > > hang?
> > > > > > >
> > > > > > > What is wrong with that. Do you know an example for managing
> this.
> > > > > > >
> > > > > > > Thanks - Patrick
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> schrieb im
> > > > Newsbeitrag
> > > > > > > news:uVh053jpEHA.3428@TK2MSFTNGP11.phx.gbl...
> > > > > > > > The most likely source of your problem is that you're not
> using
> > > the
> > > > > > > > Form.Invoke() method to marshal the call to your UI thread
> > before
> > > > > > changing
> > > > > > > > your GUI. The callback into your client will never occur on
> the
> > UI
> > > > > > thread,
> > > > > > > > so these calls should never directly modify UI elements in a
> > form.
> > > > > Even
> > > > > > if
> > > > > > > > this seems to work for HTTP, you still need to use
> > > Form.Invoke() --
> > > > > > that's
> > > > > > > > the only guaranteed safe method.
> > > > > > > >
> > > > > > > > Ken
> > > > > > > >
> > > > > > > >
> > > > > > > > "Patrick Jox"
<Patrick@softwerk-n-o-s-p-a-m-technologies.com>
> > > wrote
> > > > in
> > > > > > > > message news:%230e%235xgpEHA.2864@TK2MSFTNGP12.phx.gbl...
> > > > > > > > > Hi,
> > > > > > > > > I have some problems with eventhandlers, that update some
> gui
> > > > > > elements.
> > > > > > > I
> > > > > > > > > have implemented an eventwrapper class, that exposes an
> event
> > > > > handler
> > > > > > > > which
> > > > > > > > > is registered to the server.event. This eventhandler then
> > fires
> > > > > > another
> > > > > > > > > event to which a gui method is registered. As long as I am
> > using
> > > > > tcp,
> > > > > > my
> > > > > > > > gui
> > > > > > > > > hangs. I tried around with several ideas but I always had
> the
> > > same
> > > > > > > result.
> > > > > > > > I
> > > > > > > > > got an example that did exactly the same as my application
> and
> > > it
> > > > > > worked
> > > > > > > > > fine ther. The only difference was, that I was using tcp
and
> > the
> > > > > > example
> > > > > > > > was
> > > > > > > > > using http.
> > > > > > > > >
> > > > > > > > > So in a moment of crazyness i switched my application to
> http
> > > and
> > > > > > since
> > > > > > > > than
> > > > > > > > > it worked.
> > > > > > > > >
> > > > > > > > > Can anybody explain this behavior?
> > > > > > > > >
> > > > > > > > > I thought, that the protocoll should not influence my
> > > > implementation
> > > > > > so
> > > > > > > > > deep?
> > > > > > > > >
> > > > > > > > > Any Ideas?
> > > > > > > > >
> > > > > > > > > Thanks - Patrick
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>