Diese Seite mit anderen teilen ...

Informationen zum Thema:
WinDev Forum
Beiträge im Thema:
Erster Beitrag:
vor 2 Jahren, 6 Monaten
Letzter Beitrag:
vor 2 Jahren, 6 Monaten
Beteiligte Autoren:
CCC2, Peter Holemans, Fabrice Harari, Danny Lauwers

[WM20 -android] Beware Bug in Concatenation string

Startbeitrag von CCC2 am 26.08.2015 07:53

bug appear in WM20-android
There is bug in concatenation string .

when try to Concatenate ( using "+" or arraytostring()) of the following character

ascii code

for example
m_str is sting = ""
m_str += charact(129)

info(asc(m_str)) -> will return 65533


weird part is if do like this

info(asc(charact(129))) -> will return 129

i have try declare variable as ansi string but same result and only on those ascii code.

von CCC2 - am 26.08.2015 08:12
problem with the string

here the test code
M_str is ANSI string
M_cnt is int

FOR M_cnt = 1 TO 255
M_str = ""
M_str = Charact(M_cnt)

IF Asc(M_str) M_cnt THEN Info(M_cnt , Asc(M_str) )


von CCC2 - am 26.08.2015 08:20

AFAIK, it's not a bug.. It's just that android works by default in UNICODE and that you are trying to work in ANSI...

for example
m_str is sting = ""
m_str += charact(129)

Here, you just tried to add to m_Str = a UNICODE STRING charatc (129) which is clearly ANSI (one byte) so the wlanguage s doing anAnsiToUNicode for you

info(asc(m_str)) -> will return 65533

And here you are getting the correct result, the value of one unicode character (two bytes)

If you really want to work in ansi, you need to declare your string as "is ansi string"

And if you don't want to be surprised by string manipulation results, you need to delcare ALL of them as either ANSI or UNICODE, and make sure that you use the correct one everywhere.

In order to facilitate that, I'm declaring my string the following way:
asMyStirng is Ansi string
usMyString is Unicode string
ccsMyString is string //ccs standas for Current Configuration String, which means that the TYPE (ansi/unicode) depends of the current settings in the project configuration.

This is true for WM, WD AND WB, as each has that same setting in it's configuration management. The diference is that the DEFAULT is unicode for WM, ansi for the other 2.

Best regards

von Fabrice Harari - am 26.08.2015 09:39
Hi Fabrice,

this is not problem cause by unicode /ansi , I have tested both.
the problem does not occur on WD20 .

the problem only occur on those 5 code , the rest is ok . I don't think ansi/unicode problem will only effect these 5 code.

von CCC2 - am 26.08.2015 10:01

I have to agree with Fabrice.
It smells like an ANSI/Unicode issue here but somewhere in your code.

A simple new WM project with a Unicode configuration flagged on and one window and a couple of lines of code will prove it is really a WM bug or not. To be honest, I doubt it...

Therefore, what is your current project configuration? Is it defined as Unicode?
Since V18 all my project configurations are Unicode only.
I haven't had any issues anymore whatsoever between platforms and multi-product (WD/WB/WM) development.
And moreover I don't need to do any of these inline ANSI/Unicode/UTF conversions anymore...

I would recommend making all (surely any new project) your WX configurations Unicode.
A wizard will show you all potential code snippets to review if there is a potential conflict.

Best regards,

Peter H.

von Peter Holemans - am 26.08.2015 10:31
Hi Peter,

The problem occur when i create function to convert json data to image which i posted in here

on WD20 and WM20 I set to unicode . on WD20 no problem after UnicodeToAnsi() but on WM20 different , the image become distorted . after i compare the hex of the original image and image generate by WM20 function i create, I found the following ascii code are not convert correctly
ascii code

at first I suspect problem with UnicodeToAnsi() , I change the variable declaration to ansi string , then i notice , only this 5 code and only in WM20-android , the value change whenever i try to store into variable .

I can't use unicode because the final filesize become double . this is why i need convert it to ansi.

von CCC2 - am 26.08.2015 11:27

Just had a look at your initial post. Indeed, it is a bit particular with the JSON conversion at first...

If you have different results between WD and WM then I would create a simple test project (the same project you open with WD and WM), create a WD and a WM window that does the conversion and send it to PCSoft support if the result is not the same.

I'ld expect that the result between WD and WM should indeed be identical for the same string and with the same project configuration (Unicode).

Just my 2 cents,

Peter H.

von Peter Holemans - am 26.08.2015 11:58
Hi Peter,

Thanks .

make sure to final result convert to ansi .

von CCC2 - am 26.08.2015 12:10

I guess there's a misunderstanding here...

I'm not saying I will create such a project; I was just saying what I would do if I was experiencing your issue. (==> "I would"... vs "I will"...)
It's probably only a 10 minute job to create such a project...

If next you are able to replicate the issue in that sample mini-project and it is confirmed to be a PCSoft bug I'm sure PCSoft will provide you with a personal fix as this is definitely a critical one.

So, build that project, replicate the issue and send it to PCSoft...

Best regards,

Peter H.

von Peter Holemans - am 26.08.2015 14:19

It been years that whenever i email them , other than auto reply when i submit, i never get reply whether bugs or not . I guess i get ban from submit too much bugs reports.


von CCC2 - am 26.08.2015 14:40
I found solution

to store as buffer hex.

FOR m_cnt =1 TO M_array_Max
M_buf += BufferToHexa( Charact(M_Array[m_cnt]))

RESULT HexaToBuffer(M_buf)

this method work. only one problem . it 's very , extreme slow .

von CCC2 - am 28.08.2015 04:40
strange . for one image with size of about 20k
, it take the for loop about 5 minutes to finish on android tablet while on windows application there is no waiting time.


von CCC2 - am 28.08.2015 05:07

Maybe you can set the buffersize first to the size you want with:

M_buf is buffer on xxxx

there are other methodes of setting the size of the buffer first

and then use M_buf[[m_cnt]] to fill the buffer, then the buffer does not have to be resized with every operation.

There is a big difference between Mobile and Desktop that you have to take into account. Operations that only take a second on a Desktop with lot's of memory and high speed processors and cache could take a lot longer on a limited mobile platform. Choose your code wise ;)


von Danny Lauwers - am 28.08.2015 07:03

that's because concatenating strings in android can be a very long process. I explained the ins and outs in an article available in my WXReplication articles, and it all goes down to how pcsoft implemented concatenation in java (it looks like they used the old/slow method).

So if you need to go fast, some java code mau be in order

Best regards

von Fabrice Harari - am 28.08.2015 09:55
I decide to make modification on the webservice to send the blob encode in base64 as danny suggest rather than javascript buffer.
the webservice is written in express.js run on linux . I didn't choose this option is because i not expert in nodejs , I don't know how to just encrypt blob fields only before send , bext i worry wd20/wm20 may not able to decode.

after spend hours try/error and googling , I manage to do it . using postman to test , as expected the size is increase but no obvious decrease in speed.

first I try modify the test application on WD20 . it work and speed alot alot faster. next make change on WM20 app . first i discover invalid parameter base64 in uncrypt() .
I though i have waste my time . I delete the parameter and compile and run on tablet . to my surprise it still work .

the speed is faster but not as fast compare to WD20 but it is faster than using PC-soft webservice (at least 5 times faster from my timing).

von CCC2 - am 29.08.2015 05:58
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.