VB6: socks & richtextbox

It's the one on the end. It's supposed to be a joker. The string for the smiley is this:
:P~
However since there's a :P in it it doesn't display...

the ??? - it reminded me of forgotten, somehow...

There you have it. Switch statements are for the devil (in most circumstances).

:) ;) :D ;D >:( :( :o 8) ??? ::) :P :-[ :-X :-\ :-* :'( :P~ <--- spot the odd one out

caught me all of once in PHP after 6 yrs of VB6'n... and it's never caught me out since :P

True. There isn't much in difference, but it'll still come as a shock to most VB developers when they move onto something like C++. It would have been nice if they used different keywords, rather than trying to change accepted traditions of programming languages... Though, I guess BASIC is older than even C.

Yes, there is a few tricks to the way C/PHP switch () statements are handled that help the developer some. That being said - there's nothing to say that one cannot call a subroutine or function with parameters from within a VB Select Case ... End Select structure (which i find more efficient in the long run, if only because it makes navigating code quicker, and also reduces overall codesize for commonly executed codelines).

What's different about it in C compared to VB then? the only difference that I _think_ there might be, is that C code uses a fall-through system meaning that you need to break; (is that the right keyword?) when you don't want the next case to match also.

Another difference is that the C switch structure is for integer types only. It's  not used often in C/C++, but it's very good in some cases to eliminate redundant code and speed up processing. VB's use of the switch is completely different- they've tried to make it a 'shortcut' for if... else if... end if, but in terms of legibility, once you start nesting switch statements, well I'll let you figure out what the problems are. Mostly, my hatred for VB's switch control structure is that it eliminates some, though little known, very beneficial code tweaks that can be made in C. Consider this code, which is a very basic summary of how my recent task works... of course, an interpreter that will support ANSI-C functions and loading of dlls/modules written in C/ASM/VB/Delphi is too large to paste here...

<br />
for (c = code; *c; c += strcspn(c, "(,)")) {<br />
	switch (*c) {<br />
		case '(' : {<br />
			// the code here sets up a new level of interpretation, resets the argument counter, and inserts the first argument into the code tree<br />
			// it doesn't break, and thus follows through to the next case statement<br />
			// because the code in the below statements are common to this one<br />
		}<br />
		case ',' : {<br />
			// the code here is only a few lines, so I'll just put it here. It increments the argument counter, and the total length of the script.<br />
			if (*c != '(') {<br />
				rx++;<br />
			}<br />
			ry++;<br />
			// doesn't break here either...<br />
		}<br />
		default : {<br />
			// lots of code here<br />
			// ...<br />
			// ...<br />
			// it's generally common to all the above cases</p>
<p>			// and here's where I check for the end of a statement<br />
			if (*c == ')') {<br />
				// drop back to the previous level of interpretation, and reset the arg counter<br />
			}<br />
		}<br />
	}<br />
}<br />

Yes, the C switch () {} structure needs a break; for each case, otherwise the logic structure in the next case will also fire, and the next one and so forth until the end of the structure or a break is reached (whichever comes first)

What's different about it in C compared to VB then? the only difference that I _think_ there might be, is that C code uses a fall-through system meaning that you need to break; (is that the right keyword?) when you don't want the next case to match also.

Be aware of the difference in usage of the switch/case structure in other languages. I usually wouldn't recommend that VB programmers use "Select Case/End Select", as it doesn't really make things any more readable, or improve performance. All it does is confuse the programmer when they move onto some other language for example, C++ or even C#, which is so similar to  VB .NET that a coder may as Bjarne Stroustrup once said, "to the great surprise of the uninitiated", believe that the two structures perform the same task. I'm not sure if it's even possible to use a switch statement for this in C#, and if it was I wouldn't even dream of it.

edit: said! not says...

uhh, I've quoted a copy of your code, for easy comparison.

<br />
    txtWindow.Text = txtWindow.Text & "(" & read(1) & "): "<br />
    For i = 2 To UBound(read)<br />
     tempStr = read(i) & " "<br />
     txtWindow.Text = txtWindow.Text & tempStr<br />
    Next<br />
    txtWindow.Text = txtWindow.Text & vbNewLine<br />
    txtWindow.SelStart = Len(txtWindow) - 1<br />

Here are my changes. I introduce a temporary variable, which stops txtWindow from copying it's buffer into itself so many times. For the sake of efficiency, and legibility of your code, I would encourage adopting such a line of thought:

<br />
    dim strLine as String<br />
    dim iLen as Integer</p>
<p>    strLine = "(" & read(1) & "): "<br />
    ' The loop would re-evaluate UBound(read) each iteration, which is unnecessary. I use a temp var to store this value here, too.<br />
    iLen = UBound(read)</p>
<p>    For i = 2 To iLen<br />
     strLine = strLine & " " & read(i)<br />
    Next</p>
<p>    ' txtWindow.Text copies to itself only once, instead of once per word.<br />
    strLine = strLine & vbNewLine<br />
    txtWindow.Text = txtWindow.Text & strLine<br />
    txtWindow.SelStart = Len(txtWindow.Text) - 1<br />

You may also find that this solves your problem ;)

code hint: instead of If ... ElseIf ... ElseIf ... Else ... End If, consider using Select Case ... Case ... Case Else ... End Select

try replacing

temp = Replace(temp, vbNewLine, "")

with a split on the vbNewLine, that way when you receive more than one line you can split it out into separate messages - just be sure that each command sent from the server is contained entirely on one line and that there is a vbNewLine at the end of said line.