From: rickNOSPAMnews@NOSPAMcomcast.net   
      
   >    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)