Been experimentin more with it, and with the advent of the doevents() in the dowork event, I do seem to get what I want and the completed event is nice... But I started to get the idea that perhaps this object was never meant for what I was trying to do and began to look at other threading code out there... I still was havin a prob, starting a thread (thread object) and gettin it to run like I wanted, here I was coding for framework 2 and my guess is currentthread.sleep method disappeared which may have been what I wanted... so I was not gettin async processing with that object either... I ran across an asynccallback object with a begininvoke method - I was a little lost with it, created a delagate, issued a begininvoke() method and I'd get a routine to run but not asnyc either... I am thinking something has to have changed, because I was sure I did this once a long time ago with the thread object and the start() method, but perhaps then I used a combination of sleep() and doevents() methods to get the job done then too... maybe what Ive been tryin to do is bad practice... I do know in old vb6 programs, the advent of just one single doevents() could mess alot of things up... and since with vb.net, I've tried to code threadsafe but have had to resort to alot of synclock blocks, seems still to be a delicate practice and one that requires alot of careful consideration...  any opinions on this are glady accepted, thx again

Since you haven't posted any code, it's impossible to tell you where the problems lie, but see if this helps


Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
    Dim wk As New Worker("The String")
    Dim WkThread As New System.Threading.Thread(AddressOf wk.DoSomeWork)
    AddHandler wk.DataChanged, AddressOf UpdateUI
    WkThread.Start()
  End Sub
  Private Delegate Sub UpdateUIDelegate(ByVal data As String)
  Private Sub UpdateUI(ByVal sender As Object, ByVal args As Worker.WorkerArgs)
    If Me.InvokeRequired Then
      Dim Parms() As Object = {args.Data}
      Me.Invoke(New UpdateUIDelegate(AddressOf ChangeLabel), Parms)
    Else
      ChangeLabel(args.Data)
    End If
  End Sub
  Private Sub ChangeLabel(ByVal s As String)
    Label1.Text = s
  End Sub

Worker Class:

Public Class Worker
  Private Data As String
  Public Event DataChanged(ByVal sender As Object, ByVal Args As WorkerArgs)
  Public Sub New(ByVal SomeData As String)
    Data = SomeData
  End Sub
  Public Sub DoSomeWork()
    'simulate some work
    System.Threading.Thread.CurrentThread.Sleep(5000)
    Data &= " with changes made!!"
    RaiseEvent DataChanged(Me, New WorkerArgs(Data))
  End Sub
  Public Class WorkerArgs
    Private TheData As String
    Public Sub New(ByVal Data As String)
      TheData = Data
    End Sub
    Public ReadOnly Property Data() As String
      Get
        Return TheData
      End Get
    End Property
  End Class
End Class

I'm kind of new to Windows UI programming, so maybe there's a good reason for this that I'm not aware of this... However.

Is there a reason why allowing any thread to communicate to the UI, forcing the programmer to use critical sections (mutexes) to do this properly is a bad idea? While the delagate interface is great, it just seems like quite a bit of extra work compared to simply using a critical section to solve the race condition.

Bruce,

Hey man, thanks a million for being a trooper and trying your best to work your way through this.  I know that working through threading issues is a hard concept to grasp -- particularly if you come from a vb6 background where threads just weren't an issue -- but also not an option.  That's right, in VB6, you didn't have the option to run code asynchronously. Even calling the Windows API to create a thread wouldn't produce a truely asynchronous execution from VB6.  So, giving Threading to VB users was a challenge -- not only because of the complexity involved in providing the feature, but also in providing support to those who aren't used to dealing with the additional need.

So here goes.  First off, while your attempt to use the background worker process is a valiant one, it unfortunately isn't what you want to use in your instance.  You see, the backgroundworker component is meant to kick off asynchronous processes and then update the UI from events received from the thread. Since your socket code is already running on another thread (know it or not), there is no need to set up the background worker every time you want to update the UI.  In fact, your work is nearly finished!

Here's what I recommend.  First, create a delegate on your form called UpdateTextHandler. If you aren't used to delegates, don't panic!  I'll get you through this.  To add the delegate, add the following code under your Form declaration:

Delegate Sub UpdateTextHandler( ByVal message as String )

Second, add  a method to your form called UpdateText as follows:

Public Sub UpdateText( ByVal message as String )
     Me.LSOS.Text += message
End Sub

Lastly, update the  your MTAConnection_DataReceived method. Change any calls to update your LSOE textbox as follows:

Case "LSOE" 'SMTP Out Queue End
 Me.Invoke( New UpdateTextHandler( _
 AddressOf UpdateText ), new Object() _
 { StringData.Substring( Pos + 1, _
 StringData.Length() - (Pos + 3)) } )

You can do updates to different textboxes a million ways but let's move on for now.  Does this seems complicated?  OK. Let me explain this madness.  For ease of explanation, think of a delegate as a placeholder for a method.  A delegate allows you to connect to any method that matches the "signature" the delegate has. So, the UpdateTextHandler and UpdateLsoeText has the same signature.  I can create a new UpdateTextHandler delegate instance by passing in the addressof the method I want to execute.  Since the method has parameters, I have to pass those in as well.  That's why I have the object array after the handler I can use the object array to pass in the value to the delegate as though I was passing it to the method itself.

So how do you update different text boxes?  Here goes.  Take ALL of the code from your DataReceived event handler, and put it into your UpdateText method.  Inside your DataReceived event handler add the following code:

Me.Invoke( New UpdateTextHandler( _
   AddressOf UpdateText ), _
   New Object() { StringData } )

That should be it!  If you still don't understand what is going on, drop me a line and I'll be glad to help.

HTH,

Tobin