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 author=Imperceptus link=topic=17469.msg177911#msg177911 date=1209218493]
Is this from a memory leak?
[/quote]

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

[code]
    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
[/code]

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.  For instance:

[code]
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
[/code]

[quote author=Imperceptus link=topic=17469.msg177957#msg177957 date=1209320287]
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.

[code]
    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
[/code]

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.
[/quote]

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.