3 replies to this topic

[aclayto87]

Hi everyone (i am working in Installshield 2010)
we are trying to convert a unicode string to hex using the following code:
decimalNumber = STRTOCHAR (StringValue)
num1 = decimalNumber /16;
num2 = decimalNumber – (num1*16)
sResult = HexEquivalent(num1) + HexEquivalent(num2)

However! the characters '80'-'9F' are not supported in unicode. The original string that is given to IS is actually a string in the Windows Western character set. but when i use the STRTOCHAR it is assuming the string is in unicode and is converting it incorrectly to decimal - since some of the characters do not exist in Unicode. Is there any way to convert the string we are reading in directly into Hex? Since IS is assuming the string should be in Unicode i am getting garbage when i try to convert it back to hex if the character falls in the 80-9F range.

I looked into StrToNumHex but it only handles 1-9 and A-F so this wont convert unicode to hex

the definition of STRING in IS2010 says is is an array of Unicode characters. the string we are reading in is in Windows:Western. So this assumption by Installshield causes a problem from the very beginning. how should i handle a string that is in unicode, and convert it back to its original hex value if Installshield has converted it to the incorrect character set in the first place? is there any function in IS that can handle the conversion of the Windows:western character set?

I also found some code along the way on the Flexera forum that suggested the use of : Sprintf(szHexa,"%lX",szCar[i]);
This did not seem to work. The result was a 7 digit hex number for a one character string value. For instance i put the value 'Œ' as 'szCar' and then the result for szHera was "1F29BE0"

We have been stumped on this for a week now about how to handle a string that is passed in, in the Windows western character set, and being able to correctly convert it to hex. Please let me know if you have any suggestions. is there anything to directly convert this windows western string to hex?

thanks!
Alicia

Edited by aclayto87, 17 November 2010 - 20:51.

[Taco Bell]

I've never experienced such an issue in IS, but from reading your post, the real problem seems to be you passing Windows Western character set string to IS in the first place because the InstallShield strings are inherently unicode in nature. Therefore, the issue does not seem to really lay in you trying to then convert that string to characters. Is it not possible then for you to instead have the original string be unicode? 'cause that seems like the only way this is ever going to work.

[aclayto87]

I need to explain better. i was not entirely clear on what the entire problem was intially (its a little above my head!) What is actually happening is we are calling an external DLL from IS. The external DLL is returning an array of 6 bytes to Installshield. See below for DLL function call: (the szSR is the string that is receiving the 6 bytes)
nret = DLL_function_call(bPK, szFC, szSR, szCV);

Ok the issue arrises once we call the DLL and the 6 unsigned characters are returned, this IS string SHOULD then show chracters from 0-255 or 0 - FF, but what i am seeing in the string is a string of Unicode Characters. So somewhere in the inner workings of Installshield those 6 unsigned characters are being converted from their actual values to unicode, which is not something we wanted. is the Data Type 'STRING' in installshield 'helping' us out? I hope this makes sense this time, that the DLL is actually sending an array of 8 bit characters back to IS, these 6 bytes should not be and are not unicode characters, they are values either from 0-255 or 0-FF, but it seems that IS is converting them to Unicode when it is giving me the value for the string 'szSR'.
We ultimately are wanting to recover the hex values of the original array of 8 bit characters. But since InstallShield converted the array to unicode we are getting conversion problems when converting back to hex.
For example, IS converted the array for the Hex values '8C' to 'Œ' but then when i need to convert it back to hex, the unicode value for that character Œ is 152, this is obviously not the correct original hex value..

Please let me know if i need to give any more detail, we are really stumped on this one! thanks!

Edited by aclayto87, 18 November 2010 - 23:03.

[Taco Bell]

I think you explained it fairly well before and it may be an array of 6 bytes that's coming back from the DLL, but you're assigning the results to an IS string which is automatically in unicode format and therefore the values are being converted on-the-fly.

It seems like you need to create a second DLL function that would call the first one in order to get non-unicode string, then have it do the hexadecimal conversion, and return those results to IS. That way the unicode aspects no longer come into play.