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