Hi,
from my perspective of view you should avoid to manipulate a textbox's content ( or a variable's content) in different places in your code "at the same time", if you don't have implemented some mechanisms to synchronize them.Look at the red arrows i inserted below:
serial1.Output("AAAAAAAAAAAAAAAAAAAAAA")
TextBox2.Text = "AAAAAAAAAAAAAAAAAAAAAA" '
TextBox2.Refresh
'Msgbox("break")
TextBox1.Text = "" <----------
casovac
serial1.Output("BBBBBBBBBBBBBBBBBBBBBB")
TextBox2.Text = "BBBBBBBBBBBBBBBBBBBBBB" '
...
Sub Serial1_OnCom
char = serial1.InputString
buffer = buffer & char
TextBox1.Text = TextBox1.Text & buffer <--------
buffer = ""
End Sub
You send out the string, and shortly after this you clear the TextBox1 content.Virtually in parallel your OnCom event is also manipulating the Textbox1 content.Since you don't know, which of both "Textbox1.Text = " will occur first, this is kinda race condition.At the moment it looks like, the statement in the main part is winning this everything.So you end up in this order:
Textbox = ""
serial.output first string
Textbox ="" <--you clear the empty box, because the OnCom didn't trigger yet
OnCom <--- Textbox gets filled with first string
wait a second
serial.output second string
...
OnCom <--- Textbox adds the second string
In other words: you clear the textbox that was already empty and then the OnCom Event puts in the first string.
If you put in a wait loop in here:
serial1.Output("AAAAAAAAAAAAAAAAAAAAAA")
TextBox2.Text = "AAAAAAAAAAAAAAAAAAAAAA" '
TextBox2.Refresh
'Msgbox("break") <--- wait a bit here
TextBox1.Text = ""
Although a wait loop is not safe ( some factors like send string length may vary), it would be a workaround for your particular piece of code.In real world you would need to ensure that all bytes of your string have been received by the buffer, so you know the textbox can be cleared.You could also place something like an end-of-line character at the very end of your string, if your OnCom detects this character, it clears out the textbox.
regards,
TWELVE