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.Caption = Mid(Data, 7)
Exit Sub
End If

List1.AddItem (Data)

help is appreciated.

On Sat, 30 Dec 2006 12:19:20 +0100, "313 Games"
<EMAIL REMOVED> wrote:

>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.Caption = Mid(Data, 7)
> Exit Sub
> End If
>
> List1.AddItem (Data)
>
>help is appreciated.

Mid(Data, 1, 6) = "/topic"

0 instead of 1 will throw an error

Personally I would use Left( Data, 6) = "/topic"

Incidentally Mid$( Data, 1, 6 ) and Left$(Data, 6) are faster, the $
returns a string while without the $ you get a string in a variant.

thanks, it works fine now

but now i got another question,
when the winsock sends a message when connected (as client), the server WILL
get it, but without any data in the string sended.

whats the problem? i've tried it on server @ localhost and server @ other
local computer, both didnt work.

On Sat, 30 Dec 2006 12:35:41 +0100, "313 Games"
<EMAIL REMOVED> wrote:

>thanks, it works fine now

>but now i got another question,
>when the winsock sends a message when connected (as client), the server WILL
>get it, but without any data in the string sended.

>whats the problem? i've tried it on server @ localhost and server @ other
>local computer, both didnt work.

Beats me - that is a bit of an open question.

> 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 p***ed ByRef (by reference)... a parentheses-encased
argument will force VB to p*** 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 p***ed value, multiplies it by itself and
then uses the fact that it was p***ed ByRef to send the updated value back
to the calling code by ***igning the new value directly to the p***ed
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 p***ed
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

"Rick Rothstein (MVP - VB)" <EMAIL REMOVED> wrote in message
news:EMAIL REMOVED. ..
>
> 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.
>

I have adopted the opposite habit, that of always using Call with subroutines,
and the parentheses along with it.

My main reason? In the course of development, many subs turn into functions -
that is, a return value from the procedure becomes useful, even if it is just a
boolean indicating success or failure.

If I have written Call Test(X,Y), it is then easy to turn it into Z = Test(X,Y).

I suspect that I also like seeing arguments listed in parentheses when reading
code, and it is the more common standard in other languages.

>> 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.
>
> I have adopted the opposite habit, that of always using Call with
> subroutines, and the parentheses along with it.

I was originally going to write that this option doesn't exist with Methods,
but it seems I would have been wrong... this is a new one for me, but I
tried using Call with a Method and it worked seems to work fine. For
example...

Call Me.Move(1000, 2000, 3000, 4000)

While you didn't post this directly, your post did lead me to learn
something new today. Thanks.

Rick

>>> 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.
>>
>> I have adopted the opposite habit, that of always using Call with
>> subroutines, and the parentheses along with it.
>
> I was originally going to write that this option doesn't exist with
> Methods, but it seems I would have been wrong... this is a new one for me,
> but I tried using Call with a Method and it worked seems to work fine. For
> example...
>
> Call Me.Move(1000, 2000, 3000, 4000)
>
> While you didn't post this directly, your post did lead me to learn
> something new today. Thanks.

Oh! I should have mentioned... personal preference... I still prefer
**not** to use the Call keyword.

Rick

"Rick Rothstein (MVP - VB)" <EMAIL REMOVED> wrote in message
news:IOCdnTz-EMAIL REMOVED...

>
> Oh! I should have mentioned... personal preference... I still prefer **not**
> to use the Call keyword.
>

Do you know of anything I should know as a reason not to, or is that just
personal preference?

>> Oh! I should have mentioned... personal preference... I still prefer
>> **not** to use the Call keyword.
>>
>
> Do you know of anything I should know as a reason not to, or is that just
> personal preference?

Strictly a personal preference... to me, the Call keyword is in the same
category as the (non-object oriented) Let keyword... it is not required so
it is superfluous.

Rick