[WX] Update 75t#

Just got a new update to the English version of WX. Anyone have any info about what this fixes?

[blogs.pcsoft.fr]

For me the problems with SDK 28 continue.

Ruben

time to bang PCS door

Hi, I'm sorry, we have no info about changes in Fix #1.

Kind regards,
Guenter Predl
office@windev.at

Doesn't fix the bug affecting my project either

Hi, there is some info to be read now:

* This pack contains improvements for the following aspects:

- compilation and execution of applications in Android and in particular the transition to API28 of the Google sdk,
- WEBDEV deployment in zero-downtime mode,
- an update of the Word Processing control,
- custom setup (WDSETUP).
After installing, the number of your version will be 75t#.

Kind regards,
Guenter Predl
office@windev.at

Hi. First point is not working for me. If i set the TargetSDK to 28 then the HF functions finish with errors in 64 bits devices with Android 9. They works fine if my TargetSDK is 26. I sent time ago a sample to PCSoft support.

Rubén

recently I found few strange things in WM24

1. for HFsql classic file integrating in APK, when modify table in analysis . (this what often causing crash)
- must manual run hmodfic if not run.
- make sure delete apk in exe before compile . when compile WM didn't take in the new modified HFSQL classic file. if apk is found
- manual uninstall apk in android device . when deploy using WM, it won't delete or replace the HFSQL classic file if found.

- after you have done above and you find the file still not update , in compile -> integrating file , remove and re add


2. sometime need internet when compile.

3. Compiler /Debugger dumber than previous version.

for example you remove a field / change field name in a HFSQL classic table in analysis. WM won't a fully update in program and won't show warning. will let you compile and when you run into part that has use the remove /modify field the your app will crash

compilation error log won't show anything. be careful, typo can cause you hours to find


I don't think WM24 is ready for production use

Hi

once DateToString(Date) has been a good function with no compilation error, because Dates are strings of format "YYYYMMDD" anyway, for example up to v23 the result was 20190730. An equivalent to NumToString(1234) which returns "1234" as a string. Most times such a type conversion is even automatic. Now, in v24 the function DateToString(Date,"YYYYMMDD") requires a parameter for the format of the string! Omitting this parameter will drive WINDEV AND WINDOWS 10 totally crazy! You have to restart the computer!!

Bad: LIEFERDATUM = Open("Form_LIEFERDATUM_EINGABE",DateToString(LIEFERDATUM))

Good: LIEFERDATUM = Open("Form_LIEFERDATUM_EINGABE",DateToString(LIEFERDATUM,"YYYYMMDD"))

Kind regards,
Guenter Predl
office@windev.at

Hello Guenter

Thanks for the heads up.
I have 1,600 + occurrences of datetostring() in one app and all without the format information. Most can be changed with about a series of find and replace where the field names are common but there are still around 400 to change by hand.

This is obviously linked to the problem with data masks showing incorrectly and it seems like they have screwed up something fundamental with their date handling.

The problem is that while developers correctly regard these things as bugs, they won't be regarded as such by PCSoft so they will never get fixed.
PCSoft's promise, of being able to just recompile and run with a new version is looking to be quite an empty promise.

Regards
Al

Hi Al,

the weird thing is that all of those instances are not flagged as compilation errors but while testing they show up as errors. Sometimes there is a weird WINDEV 5.5 error window shown. After that you will not be able to use either WINDEV or Windows 10, everything is delayed, memory usage goes to maximum (3,2 Gb) it slows down the whole computer. You have to restart the computer. I tested it on my two development machines, a Xeon / 12 Gb and an i5 / 8 Gb one, both react the same way.

Kind regards,
Guenter Predl
office@windev.at