Happens randomly in my socket class. Is this from a memory leak?
The Undo operation encountered a context that is different from what was applied in the corresponding Set operation. The possible cause is that a context was Set on the thread and not reverted(undone).
Quote from: Imperceptus on April 26, 2008, 09:01 AM
Is this from a memory leak?
Probably not. It seems to have something to do with multithreaded applications, perhaps something dealing with the winsock's asynchronus events?
Yeah. I have plenty of asynchronous socket stuff going on. Tracked it down into my send procedure after the sync lock. might need to rebuild the class smarter. joy.
Are you doing:
* Application.DoEvents()
* Updating your GUI
* Using Remoting across thread boundaries
in your application?
From what I've seen here (http://forums.microsoft.com/msdn/showpost.aspx?postid=173873&siteid=1&sb=0&d=1&at=7&ft=11&tf=0&pageid=1) it seems to indicate that you're updating the user interface across thread boundaries. This is not permitted in Win32; use the ISynchronizeInvoke interface (exposed by the Control class) to marshal your update calls back to the UI thread.
Generally I don't like working with async sockets. I do all the marshaling myself.
I have no clue how to do the marshaling myself. and yes i am beginning to hate async sockets.
I think its happening after the synclock. Im not too sure because the error doesn't point out whats doing it. so i put debug statements around and this is the last print before the error.
Public Sub Send(ByVal Message As String)
Debug.Print("send")
Dim bytes() As Byte = _
System.Text.ASCIIEncoding.ASCII.GetBytes(Message)
Try
SyncLock _Socket
_Socket.Send(bytes, bytes.Length, SocketFlags.None)
End SyncLock
RaiseEvent DataSent(Message)
Catch ex As Exception
RaiseEvent SocketError(ex)
End Try
End Sub
I do have the base of the project written in vb6 (got tired of this stupid error in .net) , but I would really like to know how to accomplish it in .net.
Using SyncLock/lock (the Monitor class) doesn't synchronize threading to the UI thread. It synchronizes access to a section of code via an instance of an object.
In order to synchronize UI updates you use the ISynchronizeInvoke interface (http://msdn2.microsoft.com/en-us/library/system.componentmodel.isynchronizeinvoke.aspx). For instance:
Private Delegate Sub AddChatCallback(ByVal text As String, ByVal color As Color
Private Sub AddChatImpl(ByVal text As String, ByVal color As Color)
' the addchat code
End Sub
Public Sub AddChat(ByVal text As String, ByVal col As Color)
Dim ac As New AddChatCallback(Me.AddChatImpl)
Dim parameters(2) As Object
parameters(0) = text
parameters(1) = col
If richTextBox.InvokeRequired Then
richTextBox.BeginInvoke(ac, parameters)
Else
ac(text, col)
End Sub
Quote from: Imperceptus on April 27, 2008, 01:18 PM
I have no clue how to do the marshaling myself. and yes i am beginning to hate async sockets.
I think its happening after the synclock. Im not too sure because the error doesn't point out whats doing it. so i put debug statements around and this is the last print before the error.
Public Sub Send(ByVal Message As String)
Debug.Print("send")
Dim bytes() As Byte = _
System.Text.ASCIIEncoding.ASCII.GetBytes(Message)
Try
SyncLock _Socket
_Socket.Send(bytes, bytes.Length, SocketFlags.None)
End SyncLock
RaiseEvent DataSent(Message)
Catch ex As Exception
RaiseEvent SocketError(ex)
End Try
End Sub
I do have the base of the project written in vb6 (got tired of this stupid error in .net) , but I would really like to know how to accomplish it in .net.
This may be off base, bur assuming you're writing a client application why not use blocking i/o?
Probably a hell of a lot less complex than Async sockets.
Spawn one or two threads and bam you're done.
The only problem with doing blocking I/O is that the number of wait handles becomes unwieldy on server applications. But yes, it's way easier to managed. (Although you still need to use ISynchronizeInvoke if you're on a background thread).
I will have to put it on my list of things to learn how to do. that list is dwindling fast work went from challenging to not challenging by any programmer.