I may have answered this myself. A "newObjects.utilctls.SFBinaryData" object may give me what I need, at least to bypass the overhead of conversion to a hex string and then back to a Byte array. I'll still have to iterate over the returned values (Integers) from the API calls, but at least this should be a little less work for the poor old device's processor.
--- In [email protected], "michiman56" <rriemer...@...> wrote: > > Yes, it is true that VBScript will throw an exception as soon as you try to > "touch" a Variant containing anything of Byte subtype. I'm well aware of > that long-standing limitation on the desktop as well. > > You can perform limited manipulation of Byte arrays though using helper > objects. On the desktop ADO.Stream objects can be very handy helpers. > Msxml2.Xmlhttp has a .responseBody property that returns Byte arrays and > newObject's SFStream has .ReadBin() and .WriteBin() methods that work with > them just as you described. > > A really LONG way around might be to take results back from a DECLAREd call > (as Integers) and convert these to a hex string and then back once more to > get a Byte array using newObject's StringUtilities... > > ... but seriously, folks! ;) > > No, both memory and cycles are too precious on a CE/WM device. I'll need to > think about this more I guess. > > Thanks for the heads up though. This was valuable feedback. > > - Bob -- You received this message because you are subscribed to the Google Groups "nsb-ce" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nsb-ce?hl=en.
