WinFBE Suite 1.7.8 (September 4, 2018)

[Paul Squires]

Version 1.7.8 (September 4, 2018)
- Added: Resulting file size of successful compiled EXE now shows in the status bar.
- Fixed: Compile error output not correctly parsed in cases where filenames contain embedded parenthesis.
- Fixed: Situation where editing property and switching to different control could cause the property value to transfer to that control incorrectly.
- Changed: FB 32/64 compilers updated to Sept 2, 2018, nightly build.
- Changed: GCC compiler updated to version 8.1.
- Changed: Merged both 32 and 64 bit FB compilers into one folder.
- Changed: Updated code (WinFBE, WinFormsX, WinFBX) to prevent warnings due to stricter CAST type checking in latest FB nightly build compiler.
- Changed: Successful compile popup messagebox will now display in cases where only compiler warnings (and no errors) exist.
- Changed: Environment option "Hide successful compile results message" changed to "Hide compile results message (popup)". Non-English language files will need to be updated.

https://github.com/PaulSquires/WinFBE/releases

[Joerg B.]

Good morning Paul

Thank you for the new version!
Can you take a look at the paths?
For example, after installing WinFBE 1.7.8 the following path will be entered: "EWinFBE_Suite\FreeBASIC-1.06.0-win32\fbc.exe"
The path information ":\" is missing here.
Somehow the returns disappear when saving the posts.

[Marc Pons]

Hi Paul
Just checked your last suite update, installed full on d:\   win10

Found a bug on the user tools path, and be reproduced with
when opening winfbe (same with 32 or 64 version) the 2 exe from user tools work correctly, but if you want new file (bas) and try compile-execute
you are asked to save it, so you save it : no problem for compilation execution
but after you are not able to execute user tools ,
the path of the user tools is not complete   ex  shown error  D\UserTools\asccichart32.exe    in place of  D:\WinFBE_Suite\UserTools\asccichart32.exe

apparently something wrong with the current path...

i also modified the french lang file to update it according your changes

[Paul Squires]

Hi Paul
Just checked your last suite update, installed full on d:\   win10

Found a bug on the user tools path, and be reproduced with
when opening winfbe (same with 32 or 64 version) the 2 exe from user tools work correctly, but if you want new file (bas) and try compile-execute
you are asked to save it, so you save it : no problem for compilation execution
but after you are not able to execute user tools ,
the path of the user tools is not complete   ex  shown error  D\UserTools\asccichart32.exe    in place of  D:\WinFBE_Suite\UserTools\asccichart32.exe

apparently something wrong with the current path...

i also modified the french lang file to update it according your changes

Hi Marc, thanks for the French language file - I appreciate it!

I was able to find the source of the problem to the User Tools issue. It is a combination of the relative paths being used in the Command name and the changing of current directory when a source code file is compiled and ran. I have added code to do a AfxPathIsRelative check.

I will upload a fixed package today after I look at Joerg's issue which may be similar.

[Paul Squires]

Good morning Paul

Thank you for the new version!
Can you take a look at the paths?
For example, after installing WinFBE 1.7.8 the following path will be entered: "EWinFBE_Suite\FreeBASIC-1.06.0-win32\fbc.exe"
The path information ":\" is missing here.
Somehow the returns disappear when saving the posts.

I am trying to reproduce this problem but unable to so far.
The location and name of the compilers have changed in the latest version. It seems that somewhere in the WinFBE code the previous (now incorrect) path is being loaded and changed.
Try setting the path using the "..." button to navigate to the fbc32.exe and/or fbc64.exe compiler files. See if that makes the error disappear.

[Joerg B.]

See if that makes the error disappear.

Hi Paul
Changing the path specification with the "..." button fixes the restriction.

[Joerg B.]

Hi Paul

...... if you upload an updated package..... then you can still pack the current German language package.

You are still using the "older" compiler from August as far as I have seen.
The new compiler bloats up the exe without changing the source code.

....nothing is more constant than change.   

[Paul Squires]

If you are compiling for 64 bit, then WinFBE is now using the newer version GCC 8.1
If you want a smaller EXE size, then add the -O 2 compile switch to the file or project. It will dramatically reduce the file size. Do not use -O 3 because from what I've read on the forums, it interferes too much with code and can cause unintended errors.

[Paul Squires]

Yes, you are right, looks like when I updated the compilers to the latest nightly build that I only copied them to my working version and not the packaged version of WinFBE that I uploaded with the last release. I will put those in the new package as well.

[SeaVipe]

Hi Paul,
Thanks for the update.

I had the same problem with compiler path but your "..." fixed it.

This

Code Select Expand


Function frmMain_Initialize( ByRef sender As wfxForm, ByRef e As EventArgs ) As LRESULT

    ? IsWindow( sender.hWindow )

    Prints 0

End Function   

Function frmMain_Load( ByRef sender As wfxForm, ByRef e As EventArgs ) As LRESULT

    ? IsWindow( sender.hWindow )

    Prints 1
   
End Function   

   
   
Is this correct?

[Paul Squires]

That is correct.

You will notice in the help documentation and the help label in the Property List for the Initialize Event, it says that "Form and control window handles are invalid at this point". The Load Event says that the handles are valid.

During the Initialize Event, the class TYPE is valid (eg, Form1, txtName, etc) but the window handles are created at that point.

You should still be able to set properties and load items into listbox, etc during the Initialize event. When the Form is actually displayed - the form and controls are created and the properties applied to the newly created window handles.

[SeaVipe]

Thanks for confirming that, Paul.

[Joerg B.]

If you want a smaller EXE size, then add the -O 2 compile switch to the file or project. It will dramatically reduce the file size. Do not use -O 3 because from what I've read on the forums, it interferes too much with code and can cause unintended errors.

Hello Paul
Thank you very much for the hint. I already use the parameter -o 2 when compiling.
Whether my program is now 1K or 4K larger or smaller doesn't really matter. I only noticed it.