I have been given the following code to convert a string to a "byte array" (which is then passed to other software) but it does not appear to work. I have practically never needed to use a function and am even less familiar with the data type byte and Hex numbers. I think the Val("&H") + Mid$(QueryStr, ByteIndex * 2 + 1, 2) part is wrong (Very!). Any clues?

Data(SP_MAX_QUERY_SIZE - 1) As Byte
End Type

Global Const SP_MAX_QUERY_SIZE = 56

The first QueryStr is "0C65450C"
I think QueryLength is 8.


Public Function StringToDataQuery(QueryStr As String, QueryLength As Integer) As DATAQUERY

'This converts the query string to a query byte array
Dim ByteIndex As Integer
ByteIndex = 0
For ByteIndex = 0 To QueryLength - 1
StringToDataQuery.Data(ByteIndex) = _
Val("&H") + Mid$(QueryStr, ByteIndex * 2 + 1, 2)
Next ByteIndex

End Function

I have figured out the syntax was wrong. The following seems o.k.

Public Function StringToDataQuery(QueryStr As String, QueryLength As Integer) As DATAQUERY
'This converts the query string to a query byte array
Dim ByteIndex As Integer

For ByteIndex = 0 To QueryLength - 1
StringToDataQuery.Data(ByteIndex) = Val("&H" + Mid$(QueryStr, ByteIndex * 2 + 1, 2))
Next ByteIndex
End Function

I will be talking to the Co. that gave me the code tomorrow. The .data part I presume communicates with their program (which is linked to my code, but I have no clue exactly what their program does!). It's a shame the documentation provided by the Company is so vague. 218 pages of "developer instructions", yet you read the lot and about 200 pages tell you what the "dongle" can do, and about the other 18 vaguely hint at what the programmer has to do. Not even any examples. Rubbish. By the way the reason I am having to sort this mess out is they claim their product is VB compatible, yet their technical person says "oh, the key expects the argument to be in "c" format, so a VB string (which their own documentation says will work!) will NOT work! The VB string has to be converted to the VB "BYTE" format, then sent to the key for a response, then the response has to be converted back to a string for comparison. "Have you any programs you can email me that show how to do this?". "No". Just great isn't it! If I have no luck tomorrow maybe I'll post the product here so people can avoid it.

There are only a few words that come to mind, but "wow" says it all.

theres a big problem when trying to talk to api or c applications/libraries using VisualBasic and that's the String, actually I've been doing a fair bit of research and there is a brilliant piece on it in the MSDN library that ships with VisualBasic 6.0 Professinal edition in the Books section under Hardcore Visualbasic.

VB nativley uses unicode where it can, Windows95 through NT accepts LPSTR type strings, NT prefers LPWSTR type strings (W for Widechar otherwise known as unicode).

VB3 used HLSTR which is a pointer, to a pointer with a length attribute then to the character stream which is your regular 8-bit byte-per-char string.

VB6 uses BSTR which is a null-terminated widechar string, inside the vb programming environment "this" has a length of 4 characters, in memory it's 10 characters (counting the wNull at the tail and not including it's length record).

The Byte datatype serves two purposes, one is a single unsigned byte for use as flags or values, can be used as a 'typeless' variable to store unformatted datablobs, the other purpose is to behave just like a C/C++/Java char datatype.

The dynamic byte array is compatible with the String datatype, i.e.
Dim bText() as byte
Dim MyString as String: MyString = "COWS!"
bText = MyString

bText will contain the word "COWS!"

debug.print bText
will reveal that fact, and even MsgBox although sometimes you need to convince it to let you do it, it's not a huge drama.

bText will also contain the UNICODE version of the string unlike various routines in VB that automatically convert to ASCII/ANSI strings which for some things are absolutley useless.

A fixed sized array (even one that can be redimmed) generally and 99.9% of the time will not allow you to directly assign the VB string to it.

This is my working solution to your code, if you test it with an 8 byte entry the first 8 bytes in the data array become occupied right up to the very top. PLEASE SAVE ANY CHANGES YOU MAKE BEFORE RUNNING THIS CODE, and feel free to try it in a secondary copy just in case it's not compatible at all, because if for any reason CpyMem violates memory space the VBIDE will exit with no warning!

Declare Sub CpyMem Lib "kernel32" Alias "RtlMoveMemory" (lpDest As Any, lpSource As Any, ByVal cLength As Long)
    Data(0 To 55) As Byte 'feel free to replace my array notation with your constant
End Type
Function StringToDataQuery(QueryStr As String, QueryLength As Long) As DATAQUERY
    Dim DQTemp As DATAQUERY 'because I'm bending the rules a little I do it this way
    Dim bStrTemp() As Byte
    bStrTemp = StrConv(QueryStr, vbFromUnicode) 'if you wish to preserve the unicode encoding
    'this will causee the code to change a bit, but my understandign is that you want to trim
    'the unicode encoding completley, there are two ways to go from here, one is a loop which
    'assigns each byte value to the dataquery byte array, or there'st the more direct method
    CpyMem DQTemp.Data(0), bStrTemp(0), QueryLength
    '----Disregard if you already have experience with CopyMemory----
    'I will now explain something very important, CpyMem or CopyMemory has no type checking
    'it hammers memory from one source to another to whatever size you specify
    'it is up to you to do bounds checking, i.e. that QueryLength MUST NOT be greater than
    'the .Data field, because if it is you overwrite someone elses memory and it can either
    'result in your program exiting with no warning, or crashing several programs even causing
    'a system crash. CpyMem uses the datatype ANY which is a special case for API calls
    'ANY passes a pointer to respective library, it works fine for everything EXCEPT
    'visualbasic strings so don't even bother trying it, there is a work around if you do need to
    'but it's too early in the morning for me to write it up.
    StringToDataQuery = DQTemp
End Function

CpyMem or CopyMemory plays with pointers in vb, what I've given you is pretty straight forward and can be used with everything short of the actual VB string itself (which I won't explain why at this moment)

Yes VisualBasic has pointers, No it's not very popular, Purists would have my head for even mentioning them as they can be VERY DANGEROUS if you haven't throught out carefully about how it's going to interact with something especially when there are no bounds checking or anything else.

What you do with pointers and CpyMem is entirley up to you but be aware VB will not protect you, will not enforce Type checks AT ALL when using this arrangement.

It should be noted that RtlMoveMemory is an elegant fast solution to a loop with many iterations something that at this stage VB doesn't have a real match for. AND please be aware that "RtlMoveMemory" in the Decleration at the top of the code is CaSe-SeNsITiVe!

Another point to note is that you cannot just:

CopyMemory DQtemp.Data, bStrTemp, QueryLength

why? because you're passing the API a pointer to a pointer, not a Pointer to useable memory. (don't ask, just trust me on this one), if you want to hammer data using CopyMemory/CpyMem ALWAYS make sure that the first item in the array you want to manipulate is passed.

You can even CpyMemory DQTemp.Data(4), bStrTemp(4), 4

If this has been helpful let me know, if not, disregard. But I've had some suprising success working in VB using the api.

Skip the part CByte() for type casting unless you do recalculation of the values in the string as ASC returns an Integer and at times could cause an overflow in the byte array.

Public MyByteArr() As Byte
Public Sub StringToByteArray(ByVal s As String)
Dim i As Long
    ReDim MyByteArr(Len(s) - 1) As Byte
    For i = 0 To Len(s) - 1
        MyByteArr(i) = CByte(Asc(Mid(s, i + 1, 1)))
    Next i
End Sub

Of course it's slower than copy men and stuff but it solves the problem without third party API's.

On the side of Unicode vs. ANSII code... in this case you can discard such discussions if you only use a straight forward string read into VB.

Why VB even started casting everything to Unicode is beyond me, except for one reason and that would be sales based for M$ so they force you to move over to C/C++ and cannot use simple VB to display said unicode in the legacy applications.

To bad that they dropped it, when the only thing VB needed to continue its life was unicode output support practically.


Welcome to the forums. Hope you can become a valued member but I must inform you that you are GUILTY OF NECROPOSTING!!! :) Not a nice thing to do in any formum as most people who have replied to the thread recieve an email...

Also: a much faster version would be...

MyByteArr = StrConv(s, vbFromUnicode)

thanks for the Much faster suggestion.
I was just copying in my code I just wrote for changing 32 bytes at a time.
Not much speed required for that junk snippet.

As far as Necroposting goes...
I have no clue what you're referring to as I stick to Plain English, Swedish, German and occasionally Japanese but in neither one of those do I find a dictionary explaining the term necroposting.

As far as receiving replies to threads through e-mail so do I, and most of us who have been on forums for about 15 years now, we do weed a lot of our stuff already in the inbox or simply select to not receive replies for certain threads.

If that was unpleasant for you, then I apologize.

Necro from the latin-dead, posting... got it? Well here it is again.... dead thread posting...

your function is ok but u have a problem use this
Val("&H" + Mid$(QueryStr, ByteIndex * 2 + 1, 2))
Val("&H") + Mid$(QueryStr, ByteIndex * 2 + 1, 2)

Stop griping! I just read this entry and it is already 2010!