PlanetSquires Forums

Support Forums => WinFBX - Windows Framework for FreeBASIC => Topic started by: José Roca on June 18, 2019, 02:52:58 PM

Title: FB 1.07
Post by: José Roca on June 18, 2019, 02:52:58 PM
CoderJeff has been making changes to the compiler to allow seamless integration of UDT classes that extend ZTRING/WSTRING with FB intrinsic functions.

So far, the only changes that I have needed to do to the WinFBX framework are:

Code: [Select]
#if __FB_VERSION__ < "1.07.0"
TYPE CWSTR
#else
TYPE CWSTR EXTENDS WSTRING
#endif

This makes the class compatible with the new version and older versions.

With the new version we can do:

Code: [Select]
DIM cws AS CWSTR = "Дмитрий Дмитриевич Шостакович"
AfxMsg MID(cws, 2)

instead of:

Code: [Select]
DIM cws AS CWSTR = "Дмитрий Дмитриевич Шостакович"
AfxMsg MID(**cws, 2)

Although ** is still valid and will work both with the new and the older versions.

I also have removed a wrong cast (not caught by te older versions) in the AfxBase64EncodeW and AfxBase64DecodeW functions in AfxStr.inc.

The latest builds of the compiler are available at:

http://users.freebasic-portal.de/stw/builds/

#553 (17.06.2019 05:26:33)
udt-wstring: PRINT/LPRINT/WRITE will accept UDT as Z|WSTRING (commit: 3368c2f) — coder
#552 (16.06.2019 19:50:20)
udt-wstring: allow type extends zstring|wstring (commit: 176a562) — coder
udt-wstring: LTRIM, RTRIM, TRIM will accept UDT as z|wstring (commit: f02b30d) — coder
udt-wstring: LCASE, UCASE, will accept UDT as z|wstring (commit: da305e5) — coder
udt-wstring: allow UDT->wstring conversions in astNewCONV (commit: adc12dd) — coder
udt-wstring: INSTR, INSTRREV, will accept UDT as z|wstring (commit: 7a96a53) — coder
udt-wstring: MID function will accept UDT as z|wstring (commit: 47b461e) — coder
udt-wstring: SADD/STRPTR will accept UDT as Z|WSTRING (commit: 57360ed) — coder
udt-wstring: add TYPE EXTENDS Z|WSTRING [, udt] (commit: 9220036) — coder
udt-wstring: LSET/RSET statements will accept UDT as z|wstring (commit: d5272bd) — coder
udt-wstring: MID statement will accept UDT as Z|WSTRING (commit: 135f364) — coder
udt-wstring: ASC function will accept UDT as Z|WSTRING (commit: 2e7d606) — coder
udt-wstring: STR/WSTR function will accept UDT as Z|WSTRING to return a (commit: aefa43e) — coder
udt-wstring: SELECT statement will accept UDT as Z|WSTRING to return a (commit: f2fbc61) — coder
udt-wstring: SWAP statement will accept UDT as Z|WSTRING (commit: d9a09d7) — coder
udt-wstring: IIF function will accept UDT as Z|WSTRING (commit: ff66fc1) — coder
Title: Re: FB 1.07
Post by: José Roca on June 18, 2019, 03:09:46 PM
BTW the new compilers have implemented the -strip and -nostrip options to remove or not local symbols. Without using -strip, the size of the .exe is bigger.
Title: Re: FB 1.07
Post by: José Roca on June 18, 2019, 05:12:05 PM
I have also changed all occurrences of BYREF AS CONST WSTRING to BYREF AS WSTRING.
Title: Re: FB 1.07
Post by: Paul Squires on June 18, 2019, 05:29:52 PM
Excellent, thanks Jose. I am not ready yet to upsize WinFBE to FB 1.07 but I will. I want the editor to always be using close to the latest version of FB as possible.
Title: Re: FB 1.07
Post by: José Roca on June 18, 2019, 07:58:28 PM
The main change is that you no longer will need to use ** when working with CWSTR and the new compilers. With the small conditional changes that I have made to the WinFBX classes, you can use ** with older compilers and omit ** with the new compilers. Old code that uses ** will work both with the old and the new compilers. Therefore, you don't need to change existing code.
Title: Re: FB 1.07
Post by: José Roca on June 18, 2019, 08:43:21 PM
I have needed to make a small change to the CMaskedEdit control. All the other code seems to be working correctly.
Title: Re: FB 1.07
Post by: José Roca on June 18, 2019, 08:49:04 PM
Modified WinFBX files.
Title: Re: FB 1.07
Post by: Joerg Buckel on June 19, 2019, 03:25:50 AM
Hello José

Many thanks for the adaptations.
Title: Re: FB 1.07
Post by: José Roca on June 28, 2019, 05:52:23 PM
I have made some small modifications in the declarations to deal with constant ansi strings.
Title: Re: FB 1.07
Post by: José Roca on August 28, 2019, 01:01:35 PM
I'm having problems when trying to compile with the latest released 64 bit compiler. While everything works fine with the 32 compiler, the 64 bit one doesn't find "windows.bi".

Command Line:
C:\Programs\WinFBE\FreeBasic-1.07.0\fbc64.exe -m "C:\Programs\Tests\00.bas" "" -v -s gui -i "C:\Programs\WinFBX" -w pedantic

FreeBASIC Compiler - Version 1.07.0 (08-25-2019), built for win64 (64bit)
Copyright (C) 2004-2019 The FreeBASIC development team.
target:       win64, x86-64, 64bit
compiling:    C:\Programs\Tests\00.bas -o C:\Programs\Tests\00.c (main module)
C:\Programs\WinFBX\Afx\CWindow.inc(14) error 23: File not found, "windows.bi" in '#include once "windows.bi"'

Title: Re: FB 1.07
Post by: Joerg Buckel on August 28, 2019, 02:35:04 PM
Hello José

Is this really the current version?
My currently installed compiler is shown with version 1.08.0.
Title: Re: FB 1.07
Post by: José Roca on August 28, 2019, 02:46:40 PM
It is the last version released. 1.08 must be a work in progress.
Title: Re: FB 1.07
Post by: Paul Squires on August 28, 2019, 03:10:04 PM
....I'm setting up WinFBE with the new compiler. I'll post a download link for you to try shortly.
Title: Re: FB 1.07
Post by: Paul Squires on August 28, 2019, 03:23:02 PM
Here is a first try at the integration:  https://www.planetsquires.com/files/WinFBE_Suite_107.rar

I tried a few compiles. Simple source code files seemed to compile okay for 32 and 64, but more involved source codes failed with various syntax errors. I need to read up on the big changes, or maybe there is a difference between the old 1.06 *inc files and the new 1.07 inc files.
Title: Re: FB 1.07
Post by: Joerg Buckel on August 28, 2019, 04:06:13 PM
Hello José
I also installed the current version 1.07.0 from the FreeBasic Forum.

I do not get the described error with me.
Title: Re: FB 1.07
Post by: José Roca on August 28, 2019, 04:16:07 PM
Here is a first try at the integration:  https://www.planetsquires.com/files/WinFBE_Suite_107.rar

I tried a few compiles. Simple source code files seemed to compile okay for 32 and 64, but more involved source codes failed with various syntax errors. I need to read up on the big changes, or maybe there is a difference between the old 1.06 *inc files and the new 1.07 inc files.


This new version works fine.

> but more involved source codes failed with various syntax errors

Any example that I can test?
Title: Re: FB 1.07
Post by: Paul Squires on August 28, 2019, 04:43:26 PM
Attached is a simple employee database program that I wrote to help me at work. It seems to compile for 32 bit but fails with 64 bit. I haven't done much investigating yet as to why. I removed all of the employee data from the sqlite database so I feel okay posting it here.

(EDIT: Attachment removed as it is no longer needed)
Title: Re: FB 1.07
Post by: José Roca on August 28, 2019, 06:46:19 PM
Most are problems of incorrect casting (each version of the pompiler is more strict)

Code: [Select]
nIndex = frmEmployees.lstEmployees.Items.Add( pStmt.ColumnText(wszColumnName), cast(long, pData) )
--- must be
nIndex = frmEmployees.lstEmployees.Items.Add( pStmt.ColumnText(wszColumnName), cast(INTEGER, pData) )

dim pData as longint ptr = cast(longint ptr, frmSetup.lstData.SelectedItem.Data32)
--- must be
dim pData as longint ptr = cast(longint ptr, CAST(INTEGER, frmSetup.lstData.SelectedItem.Data32))

if combo.SelectedIndex > -1 then pData = cast(CWSTR ptr, combo.SelectedItem.Data32)
--- must be
if combo.SelectedIndex > -1 then pData = cast(CWSTR ptr, CAST(INTEGER, combo.SelectedItem.Data32))

frmSetup.lstData.Items.Add( pStmt.ColumnText(wszColumnName), cast(long, pData) )
--- must be
frmSetup.lstData.Items.Add( pStmt.ColumnText(wszColumnName), cast(long, CAST(INTEGER, pData)) )

They have also modified windowsx.bi

Code: [Select]
nIndex = ComboBox_FindStringExact( frmSetup.comboLevel.hWindow, -1, pStmt.ColumnText("grouplevel") )
--- must be
nIndex = ComboBox_FindStringExact( frmSetup.comboLevel.hWindow, -1, STRPTR(pStmt.ColumnText("grouplevel") ) )

I haven't yet found the correct syntax for DELETE.
Title: Re: FB 1.07
Post by: José Roca on August 28, 2019, 06:57:12 PM
For DELETE it seems that you will need an intermediate step:

Code: [Select]
delete cast(sqlite3_int64 ptr, CAST(INTEGER, combo.Item(i).Data32))

--- change to:

DIM p AS INTEGER PTR = CAST(INTEGER PTR, CAST(INTEGER, combo.Item(i).Data32))
DELETE p

Code: [Select]
delete cast(LONGINT ptr, frmSubstantive.lstTeams.Item(i).Data32)

--- change to:

DIM p AS INTEGER PTR = CAST(INTEGER PTR, CAST(INTEGER, frmSubstantive.lstTeams.Item(i).Data32))
DELETE p
Title: Re: FB 1.07
Post by: José Roca on August 28, 2019, 07:00:19 PM
Too many pointers stored as longs, and longs stored as pointers...
Title: Re: FB 1.07
Post by: Paul Squires on August 28, 2019, 08:07:44 PM
Thanks Jose, I made all of the changes and got it to compile. This application only runs in 32 bit because I am using 32 bit DLL's for sqlite and libharu. Hopefully the resulting 64 bit exe is actually a good exe.

All of the CAST's are because in my WinFormsX library I have a generic LONG value for most items (ie the Data32 property of a combobox item, etc). I was using that area to store pointers to larger structures (sqlite 64 bit pointers). It is a pain to have to do the CAST to and from INTEGER. It seems that you only need that in the 64 bit compiles. The 32 bit compiles did not need the CAST's or changes to the DELETE.
Title: Re: FB 1.07
Post by: José Roca on August 29, 2019, 03:23:00 PM
In the 32 compilers, the size of pointers and longs are the same, but in the 64-bit compilers not. Therefore, you must make sure that both are the same size. I have used INTEGER because it evaluates as 32-bit or 64-bit. In 32-bit you don't need CAST(INTEGER, combo.Item(i).Data32)), because it will cast a long to a long, which is redundant, but in 64 bit we need to cast the 32-bit value to a 64-bit value. Keep in mind that the 32-bit compiler uses gas (an assembler) by default, whereas the 64-bit compiler uses gcc, which is a c++ compiler with strict type checking.