WinFBE Suite 2.1.0 (April 6, 2020)

[Paul Squires]

Version 2.1.0 (April 6, 2020)

Editor:
- Added: New caching system that should speed up large project loading. Parser database saved between sessions.
- Added: New Environment Option "Enable fast project cache" in support of the newly added project caching system that was added.
- Added: New WinFBE_Suite updates will no longer overwrite existing WinFBE.ini, user_snippets.ini, and freebasic_keywords.txt files.
- Added: Environment Settings / Code Editor option called "Position searches to middle of screen" to enable/disable positioning search found text to the middle of the screen.
- Added: Find in Files new options to restrict search to "Current Document, "All Open Documents, or "Current Project".
- Added: Two new buttons on Explorer. "New File" and "New Project".
- Changed: Find In Files dialog is now modeless.
- Changed: All file operations now use Streams (using CFileStream or CTextStream classes) to replace built in FB Get/Put commands.
- Fixed: In certain cases, (Get) or (Set) would be included in the autocomplete text being entered int othe editor after selection.
- Fixed: GPF when pressing F6 on a #Include statement to load that file into the editor.
- Fixed: Non-Project user entered Command Line parameters were not being passed to compiled EXE beng run.
- Fixed: Various screen flicker during File/Save or Compile operations.
- Fixed: Improved the screen updating time for Block Comment and Block UnComment on large files.
- Fixed: Find/Replace could change the name of a sub/function. The Explorer treeview and Functions combobox are now correctly updated in the code editor.

Visual Designer:
- Added: Image Manager ability to manually edit the filename rather than having to remove and invalid path image and re-add the correct path image.
- Changed: You no longer have to manually add #Include statements for your Form files in your main .bas file.

Download it from: https://github.com/PaulSquires/WinFBE/releases

[SeaVipe]

Thanks, Paul. Really appreciate all your hard work on this big project.

[Paul Squires]

Thanks Clive - I appreciate it. I've been having more programming time lately of course because of the pandemic.

[SeaVipe]

Good evening, Paul,  "Position searches to middle of screen" places the found search string consistently on the 4th row. The middle would be 'about' the 20th row on my monitor when working with WinFBE Maximized.

[Paul Squires]

That's odd. Maybe I'm doing something different because I didn't notice that behaviour. Try highlighting a word and press "F3" to see if the next found found re-positions to the centre of the screen.

[SeaVipe]

F3 centres the find in the page only if the Find is on one page. Which is probably how you designed it.
Find In Files, Current Project places the found found on the 4th line.

[Paul Squires]

Ahhhh yes the find in files may not be centering. I'll check that. Sounds like an oversight on my part.

[SeaVipe]

:0).
Odd behaviour: I added a button to a form using Right/Click Copy then Paste. Positioned the Button, then selected the Click Event. Didn't save the project (at this point, I almost always Save but didn't) but did edit the Click Event by adding one line: ? "Click Event", __FUNCTION__. Clicked Compile and Run. WinFBE crashed sometime during compile. I've since removed the button and its related code but WinFBE still crashes. I've yet to delve into the raw form code.

[Paul Squires]

I have fixed the reposition in middle of screen. There were other scenarios where it was supposed to osition to middle and it was not doing so.

I will try to recreate the issue you have described. In the meantime, try deleting the "projectname_db_data.ini" that exists in the same folder as your project's .wfbe project file and then try a recompile to see if it works.

[SeaVipe]

Hi Paul, I deleted "projectname_db_data.ini". WinFBE still crashes. "projectname_db_data.ini" does not get recreated and "WinFBE_VD_MAIN.bas" is a blank file.

[Paul Squires]

Sounds like maybe the Form file itself is corrupted? If a Form exists in the project then it should generate a WinFBE_VD_MAIN.bas file when you compile. Not 100% sure at this point. At what point does WinFBE crash? As soon as you load the project?

[SeaVipe]

WinFBE was crashing sometime during the Compile - about 10 or so seconds into it before crashing. So I deleted "projectname_db_data.ini" and "WinFBE_VD_MAIN.bas" again, but to no avail. Next, I rebooted my machine and tried again. This time (without any modifications) it compiled but threw an error: "mnemonic Not Defined" in wfxButton. This may be because when I added the new button (which started all this) I wanted the mnemonic for the button to be "c" which was already in use by the "Cancel" button. So I changed the Cancel button mnemonic to the letter "n" and set the new button to the letter "c". This error did not show up until after I rebooted.
Now, however, I cannot replicate the errors or the crashing but still can't compile because of my old nemesis "1 Error" (the Compiler Results tab is blank). The last line of the Compile Log reads: "compiling rc: C:\WinFBE_Suite\FreeBASIC-1.07.1-gcc-5.2\bin\win64\GoRC.exe /ni /nw /o /machine X64 /fo "C:\SRC\DailyJournal\TMPE582.obj" "C:\SRC\DailyJournal\TMPE582.rc ÿþ" including the 2 trailing ASCII Chr.
You may recall I've been through this before but for the life of me I can't remember what the previous fixes were. I deleted the resource file but no change. :0(
Setting any button UseMnemonics to False will throw an error pointing to this line in WinFBE_VD_MAIN.bas: "pForm->btnCancel.UseMnemonic = False". ThemeSupport is set to False for all buttons.

[Paul Squires]

Yes, I seem to remember that type of resource file error mentioned here before. I can't remember what the outcome of it was? Maybe that was time that we all had to ensure that we had the latest GoRc resource compiler downloaded from the author's site. Those temporary files (ie TMPE582.rc) are created during compiling. They mostly contain the references to IMAGES that exist in your project. The temporary file is then appended to the main program's resource file and then deleted.

[SeaVipe]

Hi Paul, I didn't notice that the Image Manager had included one image file twice. I've since removed the file from the Image Manager and all is good again...:0)

[Paul Squires]

Thanks for the update. I'll try to build a check into the code generation to detect such anomalies. Strange that the resource compiler blows up when there are duplicate defined images.