home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.comp.os.windows-xp      Actually wasn't too bad for a M$-OS      17,273 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 16,914 of 17,273   
   Newyana2 to R.Wieser   
   Re: VBScript OCX receive and supply a sa   
   22 May 24 08:24:53   
   
   XPost: alt.windows7.general, comp.os.ms-windows.programmer.win32   
   From: newyana@invalid.nospam   
      
   On 5/22/2024 2:52 AM, R.Wieser wrote:   
      
   > I beg to differer.  Its Variants are wrappers that can contain a multitude   
   > of different data types.   Hence the existence of "vartype".   
   >   
      
      Variants have subtypes. But VBS only handles. An array is just a   
   collection of data packets in a row with an array descriptor prepended.   
   Once you access a(x) you're accessing a data type. If that type is   
   not a variant then VBS can't use it.   
      
      The variant is a 16-byte package that includes an identifier for   
   the data. That and object are the only types VBS can deal with.   
   Typed languages have to define the type of data: Dim A1() as long.   
   A1 is a variant, but the data are longs. Each array member will be   
   4 bytes. If you declare Dim A2() then each member is a variant. The   
   array itself is a variant either way, but not necessarily the data. You   
   can add only integers to A2 but each member is still a vaiant of   
   *subtype* long.   
      
   >> I typically use a character-delimited string that can be converted to   
   >> array easily by the caller:   
   >   
   > I could.  But as the MS documentation to SysAllocString contains a warning   
   > about autoconversion on it I though it would be better not to use it.  It   
   > would no doubt bite me in the behind when I could least use it. :-\   
   >   
      
      I assumed you were working in VB6, using VB6 strings. If it's C++   
   then I guess you might have to specificall convert to ANSI and   
   then to variant. I'm not certain. VB deals in unicode internally but   
   by default shows an ANSI string in variables. We're normally dealing   
   with ANSI unless we explicitly convert it. I think VBS is the same.   
   Whatever the case, I assume you've been able to return strings   
   from your OCX. How could you return arrays but not strings?   
      
   >> If you want to return an array then you have to convert each array member   
   >> individually.   
   >   
   > While replying to JJ I realized that if the problem is the auto-conversion   
   > of the SafeArray when its stored into a variant by VBScript I should try and   
   > see what happens when I also provide a variant to method #1 so the SafeArray   
   > can be stored into it - possibly bypassing the auto-conversion.   
   >   
      
           A safearray is a variant. The data may be other datatypes. An array   
   is just the descriptor followed by the data. As an example, Matthew   
   Curland presented a clever way to parse strings very quickly by pointing   
   an array descriptor at the string. I've used his method to run tokenizing   
   routines. Telling VB that the unicode string data is a short integer array,   
   I can then reference each character as an integer in the array, without   
   any string handling. It's just memory addresses, after all.   
      
     For i = 0 to UBound(ArrayThatsAString)   
      Select Case i   
        Case 32 'space character   
           Do This   
        Case 34 'quote mark   
           Do That   
      
      You can't do anything like that in VBS because each array member is   
   always a variant and there's no direct access to memory addresses,   
   no matter what data type you intend to use. You could return your array   
   to VB as A1() as String, but not to VBS. If you're not declaring a data   
   type then it's variant.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca