Mid function

[313 Games]

hi,

ive got a question. im making an chat program with server and client using
vb 6. but now my problem is, i want to set a topic in each server.

i want to send the data from the server to all the clients connected, and
the client can see: ow, a topic, then /topic Bla bla bla

This is my code, maybe its less complicated.

Dim Data As String
Sock.GetData (Data)

If Mid(Data, 0, 6) = "/topic" Then
lblTopic.Captio n = Mid(Data, 7)
Exit Sub
End If

List1.AddItem (Data)

help is appreciated.

[313 Games]

thankyou , now everything works fine!! :D

grtz,
313!

"Rick Rothstein (MVP - VB)" <ri************ @NOSPAMcomcast. netschreef in
bericht news:bM******** *************** *******@comcast .com...

> Sock.GetData (Data)
List1.AddItem (Data)

You already have your answer to the question you asked; however, I wanted
to point something out about the above two lines of code from your
posting. Get out of the habit you apparently have of encasing arguments
for methods and, I will guess by extension, subroutine calls in
parentheses. Unlike other languages which **require** parentheses around
all arguments, VB doesn't. In the above statements, it won't cause any
problem; but there are cases where surrounding your arguments in
parentheses will cause an error to occur or, worse yet, no error will be
generated but incorrect results will be generated. You should only use
parentheses around arguments where they are required **by syntax**. For
arguments to methods (such as above), parentheses are never required; for
subroutines, they are required only when the CALL keyword is used to call
the subroutine.

The reason for my caution is that VB treats things in parentheses as
expressions to be evaluated (even if that thing is not really considered
an expression, such as a variable name). If your method or subroutine call
require two arguments, encasing both of them in one set of parentheses
will force an error to be generated as a comma separated list is not a
proper expression that VB can evaluate. The real problem comes with
arguments that are supposed to be passed ByRef (by reference)... a
parentheses-encased argument will force VB to pass the memory address of
the temporary memory location used to evaluate the expression and that is
what the subroutine will use to write back its ByRef argument to... which
means the original variable which was supposed to be updated by the
subroutine will not be (no error will be generated, but your results will
be incorrect). Here is a short example to show you what I mean. Paste the
following into new project's Form's code window...

Private Sub Form_Load()
Dim MyNumber As Double
' Set the value of MyNumber to a value, say 4
MyNumber = 4
' This next statement will generate the correct value
' of 16 (note that no parentheses are used).
SquareMe myNumber
MsgBox MyNumber)
' Reset the value of variable back to its original value
MyNumber = 4
' This next statement will generate the wrong value
' because it is surrounded in parentheses.
SquareMe (myNumber)
MsgBox MyNumber
End Sub

Sub SquareMe(ByRef X As Double)
X = X * X
End Sub

The SquareMe subroutine takes its passed value, multiplies it by itself
and then uses the fact that it was passed ByRef to send the updated value
back to the calling code by assigning the new value directly to the passed
argument. When no parentheses surround the argument, the variable is
updated correctly; but when the argument is surrounded by parentheses, the
variable does not get updated (the calculated variable was returned to the
temporary memory location where the "expression " was evaluated at before
being passed to the subroutine instead of the actual memory address of the
variable itself.

You will be doing yourself a big favor if you break the habit you have of
placing parentheses around arguments, now, before it becomes too ingrained
a habit to break later on.

Rick

[313 Games]

argh, too fast happy :-(

a second connection to the server program, and it does not send any data.
for that to fix, i have to restart my server. ???

313.