Diese Seite mit anderen teilen ...

Informationen zum Thema:
Forum:
WinDev Forum
Beiträge im Thema:
8
Erster Beitrag:
vor 5 Jahren
Letzter Beitrag:
vor 4 Jahren, 11 Monaten
Beteiligte Autoren:
Fabrice Harari, Steven Sitas, kingdr, Danny Lauwers

Webdev 18 63c HUGE BUG

Startbeitrag von Fabrice Harari am 30.07.2013 22:33

Hi everybody

I started using 18-63c a few days ago, and unfortunately, I just found what is for me a HUGE bug... Parameters sent to an awp page as INT on 8 can suddenly have incorrect values on the browser side...

First, why is that a huge bug? In order to use the built in replication, you need to have your records automatic ID declared as INT on 8... Which means that you cannot currently use the built in replication with a webdev awp site if you need to pass a record ID as parameter (which is kind of a basis behavior) and maybe classic and php site too, but I haven't tested)...

How to test and see the beautiful effect:
- create an empty project, type awp
- create an empty page (awp also)
- in that page, add the 3 following lines:

1. In the global declaration of the page:

PROCEDURE PAGE_NoName2Loop(i8ID is int on 8=0)


2. In the Init of page (server)

info("Server init code: "+i8ID)


3. in the Load (browser) section

Info("Browser Load code: "+i8ID)


then test the page with the simple GO button, and enter as a parameter the following value:
187462334489315337 (please do not laugh, this is a REAL life value of an ID generated by HFCS 63c when an automatic replication has been set up)...

You will see the first info (in server code) displaying the correct value, and the second displaying instead 187462334489315330 (ie the same one, except for the last digit replaced by ZERO)

Now I currently do not know if this problem occurs only with BIG values or randomly (like the well known imprecision problem of reals) and I have a loop currently running to test just that...

What I do know is that the problem occurs both in IE and chrome, which means that even though it is JS related, it seems to be coming from PCSoft own code...

I have of course transmitted a sample project to pcsoft, and I'll let you know as soon as possible what is the first value displaying the problem (currently running at 135558 and counting, so this is going to be a long, lonely, and busy night for my test computer)...

The only thing we know for sure at this point is that using "INT on 8" in webdev is currently a BIG NO-NO... Which of course completely breaks everything I was working on...

If you can spare a few minutes of your time, please test this case in your version of webdev, whatever it is (18-56, 17, older versions) and any type of site (classic and php) so that we know the extent of the problem...

Best regards

Antworten:

Hello Fabrice,
do you see the sames problem in NON AWP Pages or (even worst) in WinDev 18 apps?
Did you try to delete any "cache" in your browser?

Steven Sitas

von Steven Sitas - am 31.07.2013 09:00
Hi,

WebDev 18 63c

I tried the same, and confirm that the last digit gets 0 !!
But it is not the passing of the parameters that is the problem, it seems the convertion ??


gnUmber is 8-byte int = 187462334489315337

EDT_NoName1 = gnUmber
Info("Browser Load Code: " + gnUmber)


Will give in the editbox and the dialog box 187462334489315330

WinDev 18 63c

Tried this code in a window


gnUmber is 8-byte int = 187462334489315337
Info("Browser Load Code: " + gnUmber)


And the result is 187462334489315337

Hope PC-SOFT fixes this soon then !

Have a nice day
Danny

von Danny Lauwers - am 31.07.2013 09:33
Hi Steven

thanks for your interest... And to answer your questions:
- non awp pages: NOT tested, as stated in my original message
- windev, not tested as the problem occurs in BROWSER code (ie javascript libraries) and NOT in server code (ie windev dlls/interpretor)
- as for the cache, considering that I created a NEW project with a NEW page to make sure of the bug, there was NO cache in the browser for that specific project/page, so there was no need to delete anything specifically (but anyway, on my development machine, all my browsers are set up to delete automatically their cache each time they close)

Best regards

von Fabrice Harari - am 31.07.2013 11:46
Hi Fabrice,
I think I have found the cause of the problem :(
In javascript the maximum integer you can have is 2^53.

So that would be: 9.007.199.254.740.992

Now look at your integer vs the above maximum.

187.462.334.489.315.337
9.007.199.254.740.992

It just can't be done with a javascript integer !!!
So PCSoft must use another JS datatype ....
Seems to me like a HUGE rewrite ....

Steven Sitas

von Steven Sitas - am 31.07.2013 12:20
Hi Steven

you may be right... The problem has been sent to their developers. We'll see what they say and how fast they do something...

On my side, I removed the automatic replication and I'm writing code to clean up the IDs of all my files... I just hope that the problem appears only on big value and is not random (currently tested up to 476000... this looks like it will take forever)

Best regards

von Fabrice Harari - am 31.07.2013 13:35
Hi Fabrice,
did you get a final word from PC Soft?

Steven Sitas

von Steven Sitas - am 09.09.2013 16:38
I tried code as below in wb17 (dun have wb18 ) it looks OK to me:

n8byteInt is 8 bytes int
n8byteInt = 2^53
info(n8byteInt)
ebxControl_inWB17 = n8byteInt
//both gives good result of 9007199254740992

HTH

Cheers
King

von kingdr - am 09.09.2013 18:32
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.