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
Thanks, Paul. Really appreciate all your hard work on this big project.
Thanks Clive - I appreciate it. I've been having more programming time lately of course because of the pandemic.
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.
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.
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.
Ahhhh yes the find in files may not be centering. I'll check that. Sounds like an oversight on my part.
: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.
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.
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.
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?
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.
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.
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)
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.
I would think that when deselecting "Treat Tab as spaces" and pressing Enter, the editor should indent using a tab instead of spaces?
Quote from: ji_vildaasen on April 12, 2020, 02:06:13 PM
I would think that when deselecting "Treat Tab as spaces" and pressing Enter, the editor should indent using a tab instead of spaces?
Yes, that does make sense. The current AutoInsert code treats the leading area as spaces rather than tabs. I will look at this and make the necessary modifications.
Ok.
I just had a strange error:
If there is text on the last line of the main file of the a project, then when compiling the editor adds the file "WinFBE_VD_MAIN.bas" to the list of Modules in the project and gives an error.
ImageDestroy(ImageBox.Buffer) is the last line of text in the main project file. This is the code that wont compile:
ImageDestroy(ImageBox.Buffer)#include once "C:\Dev\Projects\ToolWindows\ToolWindows\frmTool2.inc"
#include once "C:\Dev\Projects\ToolWindows\ToolWindows\frmMain.inc"
#include once "C:\Dev\Projects\ToolWindows\ToolWindows\frmTool1.inc"
To get around it just add a new line after the last code in the main project file and remove "WinFBE_VD_MAIN.bas" from the project.
Good morning, Paul.
Interesting. Much of the issues I have been having of late revolve around a particular form file. In an attempt to see what the form file header contained I tried to open it in PosiedonFB but that app wouldn't load the file. I then tried JellyFB. Instead of displaying the contents of the file, it displayed just 3 Chr - my old nemesis (see quote) ÿþ' (Dec 152, 231 and 039) - what a coincidence! (Upon further review, it turns out that all form files from WinFBE opened with JellyFB display just the same 3 Chr.) I finally opened the file with NotePad++.
Quote from: SeaVipe on April 08, 2020, 08:45:41 PM
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.
As it turns out, there were 3 trailing ASCII Chr, not 2 as I stated in the quote above. The project still won't compile...
Hi Clive,
Yes, as you've noticed, all WinFBE form files are unicode. Specifically, UTF-16 (BOM). The 3 bytes you are noticing are the unicode "Byte Order Mark". Those are bytes are the start of a unicode file that indicate that the file is UTF-16 (actually, UTF-16 uses 2 bytes, not 3). There are other types of BOM's but that's the one that WinFBE uses for forms.
The question now is, why that BOM is attaching itself to the resource file?
It looks like the 2 byte BOM plus the apostrophe which could be the first character of the line ' WINFBE FORM
Quote from: ji_vildaasen on April 12, 2020, 02:54:43 PM
Ok.
I just had a strange error:
If there is text on the last line of the main file of the a project, then when compiling the editor adds the file "WinFBE_VD_MAIN.bas" to the list of Modules in the project and gives an error.
ImageDestroy(ImageBox.Buffer) is the last line of text in the main project file. This is the code that wont compile:
ImageDestroy(ImageBox.Buffer)#include once "C:\Dev\Projects\ToolWindows\ToolWindows\frmTool2.inc"
#include once "C:\Dev\Projects\ToolWindows\ToolWindows\frmMain.inc"
#include once "C:\Dev\Projects\ToolWindows\ToolWindows\frmTool1.inc"
To get around it just add a new line after the last code in the main project file and remove "WinFBE_VD_MAIN.bas" from the project.
Thanks - I think I know why that occurs. Should be an easy fix. I'm glad you found this because I doubt that I would ever have noticed that if I didn't terminate the last line of the main file with a CR/LF that the code generation would fail.
Thanks, Paul and @ji_vildaasen, I had deleted the WinFBE_VD_MAIN.bas before but not with the followup
Quoteadd a new line after the last code in the main project file
Now the project is compiling properly.
Whenever there is a compiler error in the main project file, the "WinFBE_VD_MAIN.bas" file is added to the project as a module. Is this correct? The only way to compile again after that is to delete the file from the project and correct the code in the main project file. Having the temporary "WinFBE_VD_MAIN.bas" file visible in the project can be nice(if you want to see the actual code that is sent to the compiler).
Edit:
I added the "WinFBE_VD_MAIN.bas" as a normal file to my project(to be able to see the code output from the editor/designer). Every time after a compile has happened and the editor receives focus after a different program has had focus, it opens the file in a new tab and ask if I want to load the latest version because it has been modified. This should probably only happen if the file is already been open in a tab?
The WinFBE_VD_MAIN.bas file is automatically generated every time a visual designer project is compiled. In the beginning, the purpose of the file was to set the #Defines for including WinFormsX code controls in order to avoid the unnecessary bloat of the entire library. The file then evolved to include the main code file and function definitions from the form files followed by #includes for all of the forms in the project. Outputting code in this fashion allows you to use Form object references throughout your project without have to ensure that the #Includes are in any certain order in your Main .bas file. Actually, you no longer have to manually #Include form filenames in your Main .bas file anymore and if you do, WinFBE attempts to comment out those lines during code generation.
In theory, the WinFBE_VD_MAIN file should never be the source of the error. The corresponding #include file should be loaded instead. I'd like to see situations where that file is forced to load as I need to fix those types of situations.
I have logged that "opens the file in a new tab rather than using the existing tab" problem. I made a LOT of changes to file handling over the last two releases so it is quite possible that this problem creeped up because of an oversight.
Hi Paul, I too have had the WinFBE_VD_MAIN.bas file loaded into a new Tab in WinFBE (a number of times). The problem I faced was that it loaded so fast and the text colouring is the same as any other .bas file that I didn't realise I was editing it. I know better now! Maybe that particular file, when loaded into the editor, could be plain text without colours?
If you guys find that file loading in the editor then please take not of where the errors are coming from so that I can backtrack and find out why the error is being triggered and why that is the file that is being loaded. Worse case, I could popup a message explaining that it is not normal for that file to be triggered as the source of a compile error.
I found the source of the GPF crash. If you have a visual designer project and the MAIN file is not open in an tab control then the compile will produce a GPF. This is because the MAIN file's buffer had not yet been initialized and WinFBE attempted to access it (null pointer).
The only time I have experienced WinFBE_VD_MAIN.bas to load is because of me writing faulty code in the main project file 😀 (and the bug you fixed when there is code on the last line).
Quote from: ji_vildaasen on April 17, 2020, 07:15:09 AM
The only time I have experienced WinFBE_VD_MAIN.bas to load is because of me writing faulty code in the main project file 😀 (and the bug you fixed when there is code on the last line).
Thanks - I have now experienced that WinFBE_VD_MAIN.bas loading problem and am writing code for it now to fix it. When an error is thrown in that file I need to load the original MAIN code file and position to the error line (rather than loading WinFBE_VD_MAIN.bas). I just need to work out the error line offset because the MAIN file is included in the WinFBE_VD_MAIN.bas file further into the file than at the start.