I have interfaced external dll which encodes some data. I whished to show the encoded values as hex values and while i was doing so i have encountered the following.
hexVal long
kodirani_podaci_trans BYTE,DIM(MAX_KODER_TRANS_LEN) !this is filled by the external dll
code
!call external dll (input,kodirani_podaci_trans)
loop jj=1 to MAX_KODER_TRANS_LEN
hexVal=kodirani_podaci_trans
message(hexVal)
if hexVal<0 !c2j vraća byte kao broj sa predznakom
hexVal=hexVal+256
end
!transform to hex string
The message of above gives me negative numbers (and thats why i have sum 256 if needed). But the clarion BYTE is unsigned, i.e. 0 to 255, as help says. I have checked and indeed the java BYTE is signed.
This is not relevant to me as i do not do BYTE calculations or LONG calculations with converted BYE, i just needed here for display purposes.
Thanks
Nenad
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Internally, clarion2java always uses int to represent numbers, doesn't matter if it is a clarion BYTE, LONG, UNSIGNED.
The only time c2j pays attention to the type is when there are memory operations, i.e. OVER, or BYTE in a GROUP is assigned from/to a STRING. Or when using the clear function.
So, Bytes in c2j will indeed hold values from 0 to 255. (they will even hold 256 and upwards, but that is another story. One of the problems with c2j is that it will not work if your code relies on integer overrun/underrun. I figured that this is okay because it is not really a technique you should be using for business programming anyway).
Suggest take a look at the code you are using to bridge from java to the DLL, I suspect problem lies there. i.e. if you are using byte arrays at this point, then this will cause issues because byte is signed. Suggest use int instead.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, i use byte. I must admit i did not fully understood why byte is signed but byte is unsigned, but anyway i just wanted to point out in case the problem is of interest.
Nenad
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have interfaced external dll which encodes some data. I whished to show the encoded values as hex values and while i was doing so i have encountered the following.
hexVal long
kodirani_podaci_trans BYTE,DIM(MAX_KODER_TRANS_LEN) !this is filled by the external dll
code
!call external dll (input,kodirani_podaci_trans)
loop jj=1 to MAX_KODER_TRANS_LEN
hexVal=kodirani_podaci_trans
message(hexVal)
if hexVal<0 !c2j vraća byte kao broj sa predznakom
hexVal=hexVal+256
end
!transform to hex string
The message of above gives me negative numbers (and thats why i have sum 256 if needed). But the clarion BYTE is unsigned, i.e. 0 to 255, as help says. I have checked and indeed the java BYTE is signed.
This is not relevant to me as i do not do BYTE calculations or LONG calculations with converted BYE, i just needed here for display purposes.
Thanks
Nenad
Internally, clarion2java always uses int to represent numbers, doesn't matter if it is a clarion BYTE, LONG, UNSIGNED.
The only time c2j pays attention to the type is when there are memory operations, i.e. OVER, or BYTE in a GROUP is assigned from/to a STRING. Or when using the clear function.
So, Bytes in c2j will indeed hold values from 0 to 255. (they will even hold 256 and upwards, but that is another story. One of the problems with c2j is that it will not work if your code relies on integer overrun/underrun. I figured that this is okay because it is not really a technique you should be using for business programming anyway).
Suggest take a look at the code you are using to bridge from java to the DLL, I suspect problem lies there. i.e. if you are using byte arrays at this point, then this will cause issues because byte is signed. Suggest use int instead.
Yes, i use byte. I must admit i did not fully understood why byte is signed but byte is unsigned, but anyway i just wanted to point out in case the problem is of interest.
Nenad