From: invalid@invalid.invalid
thankyou , now everything works fine!! :D
grtz,
313!
"Rick Rothstein (MVP - VB)" schreef in
bericht news:bMqdnbFyEaoREwvYnZ2dnUVZ_qKknZ2d@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
>
>
>
>
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
