Not logged in. · Lost password · Register
Forum: agsXMPP RSS
VS2005 Erratta
Avatar
bbach 2005-09-15, 00:39 #1
Member since Sep 2005 · 3 posts
Group memberships: Members
Show profile · Link to this post
Subject: VS2005 Erratta
Greetings,

When attempting to use the XMPP component, along withe the mini client example the following error occurs while using Visual Studio 2005 Release Candidate (this also occurs in the beta 2):
Cross-thread operation not valid: Control 'rtfDebug' accessed from a thread other than the thread it was created on.

The error also occurs in the other debug area, and then again here:
        private void XmppCon_OnRosterStart(object sender)
        {
            // Disable redraw for faster updating
            lvwRoster.BeginUpdate();
        }

I then recompiled the agsXMPP dll accordingly, along with the client and still receive these errors.

What might the cause and solution be?

Thank you
Ben
Avatar
Alex 2005-09-15, 09:07 #2
Member since Feb 2003 · 4449 posts · Location: Germany
Group memberships: Administrators, Members
Show profile · Link to this post
hi,

the library is using threads. So the events are raised from another thread than the GUI Thread in the Mini Client. Some GUI controls are not Thread safe and need invoke for that. But i never had problems with the RTF control so i didnt add it there. Look in the MiniClient in the OnMessage and OnPresence events. InvokeRequired and BeginInvoke is the way to go there.
Does VS 2005 show an error or a warning?

Alex
Avatar
bbach 2005-09-15, 18:10 #3
Member since Sep 2005 · 3 posts
Group memberships: Members
Show profile · Link to this post
Thank you Alex. Yes, it is a full exception durining the running. That said, the same error strangely occurs within the chat form as well, but only after running for a little bit.

I did notice there is a setting that apparently can disable the cross-thread behavior of VS 2005 and make it operate as VS2003. If you are interested I can post it here.

Is there anything that we can do to add some plumbing so that there is no need to put in all of the invoke work? Such as a wrapper around the main connection class?
Avatar
Alex 2005-09-15, 20:55 #4
Member since Feb 2003 · 4449 posts · Location: Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Quote by "bbach":
I did notice there is a setting that apparently can disable the cross-thread behavior of VS 2005 and make it operate as VS2003. If you are interested I can post it here.
Yes im interested at this.

Quote by "bbach":
Is there anything that we can do to add some plumbing so that there is no need to put in all of the invoke work? Such as a wrapper around the main connection class?
ya, i thought about that a while ago. Because its very annoying to write invoke code all the time. But because i had only problems with the treeview and new windows on dotNet 1.1 i wrote no code for this yet. And i was hoping that MS will improve the System.Windows.Forms in .Net 2.0 for thread safety. But when you have problems with the MiniClient then i think it got even got worse.
So we should find a solution for that.
Any ideas?

Alex
Avatar
bbach 2005-09-15, 23:19 #5
Member since Sep 2005 · 3 posts
Group memberships: Members
Show profile · Link to this post
Well it appears the code runs when adding this line to the app:
CheckForIllegalCrossThreadCalls = false;

This is in the help as a note:
You can disable this exception by setting the value of the CheckForIllegalCrossThreadCalls property to false. This causes your control to run the same way as it would run under Visual Studio 2003.

That said, I think we should come up with something to more permanently solve this issue. I will think about it, but it appears that it may be as simple as creating a wrapper around the code that has all of the invoke code there. I will try to play around with it a bit. I am not sure how many classes this would need to be implemented upon though. Would we only need to wrap the connection class or all of them? That is, where does all of the threading code take place? (i can look but thought you might havethe answer on the top of your head)

Ben
Avatar
Alex 2005-09-15, 23:43 #6
Member since Feb 2003 · 4449 posts · Location: Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Quote by "bbach":
That said, I think we should come up with something to more permanently solve this issue. I will think about it, but it appears that it may be as simple as creating a wrapper around the code that has all of the invoke code there. I will try to play around with it a bit. I am not sure how many classes this would need to be implemented upon though. Would we only need to wrap the connection class or all of them? That is, where does all of the threading code take place? (i can look but thought you might havethe answer on the top of your head)
Ben

currently all events are raised from the XmlParser thread. So i must write a wrapper around all events in the lib. The lib needs to know the main gui thread which should be the main form i think and could be passed in a property. Then the lib could check this object for invoke required and invoke the event with a the delegate or a multicastdelegate. I think i will put this on the TODO list for the next release.

Alex
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:

Forum: agsXMPP RSS