WinFBE Suite 2.1.0 (April 6, 2020)

[ji_vildaasen]

I would think that when deselecting "Treat Tab as spaces" and pressing Enter, the editor should indent using a tab instead of spaces?

[Paul Squires]

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.

[ji_vildaasen]

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:

Code Select Expand

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.

[SeaVipe]

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++.

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...

[Paul Squires]

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

[Paul Squires]

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:

Code Select Expand

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.

[SeaVipe]

Thanks, Paul and @ji_vildaasen, I had deleted the WinFBE_VD_MAIN.bas before but not with the followup

add a new line after the last code in the main project file

Now the project is compiling properly.

[ji_vildaasen]

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?

[Paul Squires]

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.

[SeaVipe]

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?

[Paul Squires]

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.

[Paul Squires]

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).

[ji_vildaasen]

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).

[Paul Squires]

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.