WinFBE v1.2.5 Preview (March 5, 2017)

[José Roca]

Seems like it is not possible to compile a single file if you have loaded a project at the same time.

[Paul Squires]

That's right. Once a project is loaded, it takes precedence over all compiling. You can not have single files and projects open at the same time. You can have Files or Projects but not both.

Let me think about it. Maybe I can change the logic but I set it up initially so that it would be Files or Projects.

[James Klutho]

Paul - I haven't tried version 1.2.5 (still on 1.2.4)  and WinFBE works pretty well for me.  The only issue I have in my workflow is the the Function List fails to update itself consistently.  In fact I see no pattern in its updating.  If I add or subtract, rename a sub/function etc., the update is not recognized.  Even adding lines to various functions will throw off the target line on other sub/functions.  Even closing a project and reopening it does not appear to update the Function List target lines.  I have been working in projects.

I don't know if your intent is have Function List auto update its target lines when opening the dialog (which appears not the case) or whatever.  When I used Jellyfish for PB I don't remembering this to be an issue.  A simple "Refresh" button in the Function List dialog would be stop gap solution if there are other issues keeping the target lines auto-updated.

Thanks
Jim

[Paul Squires]

Hi Jim, thanks for the update. I will certainly look into it. I believe that the list updates now when the source file is Saved, so if you are typing or editing long amounts of code and don't save during that time then the line offsets will be thrown off. Later on I will modify that behaviour and have the file parsing monitored through threads but for now the easiest way was to update it when a save was initiated by the user.

[James Klutho]

The save did the trick.  What is subtle is that the files are all saved upon compiling.  But if you explicitly save from the menu, the Function List gets refreshed.  Thanks Paul.

[Paul Squires]

There is something wrong with the margins. If I uncheck the option to show the left margin and check the option to show the fold margin, when I restart the editor it doesn't display the fold symbols.

This appears to be related the issue I wrote about in the "TOFIX.TXT" text file.

(1)
The fold margin doesn't always display the folding icons.
To replicate this issue load a large code file with many folding sections. Go to the view menu and environment options. Unselect to show left margin and close the options window. Scroll down your code and you will see that the code folding icons are missing. Select show left margin again and they will appear.

I don't think it is related to the way that I have implemented the code in clsDocument.ApplyProperties (Lines 950 to 978) but you never know. Could also be related to the way the lexer was implemented in the version of the Scintilla DLL that I am using?

As usual, this looks like it was my error. in clsDocument.ApplyProperties Line 1139, when setting the fold properties I was testing for LeftMargin being active rather than FoldMargin.

Simply needed to change line 1139 to:

   If gConfig.FoldMargin Then

The fix will be in the next GitHub update.

[Paul Squires]

The save did the trick.  What is subtle is that the files are all saved upon compiling.  But if you explicitly save from the menu, the Function List gets refreshed.  Thanks Paul.

Yes that's correct. There is an option that you can toggle under "General Options" under "Environment Options" that determines whether to autosave files prior to compiling.

[Paul Squires]

GitHub updated

[Tasos Georgas]

Hi Paul.
When I try to open a *.bi file from "C:\FreeBASIC\inc\win" location, few of them do not open. The editor is "Not Responding".

[Paul Squires]

Hi Paul.
When I try to open a *.bi file from "C:\FreeBASIC\inc\win" location, few of them do not open. The editor is "Not Responding".

I am pretty sure that this is a case of the editor failing by trying to parse too many Windows include files through recursion. My plan is to prevent WinFBE from parsing the Windows Include files because I will create a set of pre-parsed Windows api files that will load depending on whether UNICODE is active or not. Sorry that the editor is blowing up currently with certain api files.

[Paul Squires]

Hi Paul.
When I try to open a *.bi file from "C:\FreeBASIC\inc\win" location, few of them do not open. The editor is "Not Responding".

I am pretty sure that this is a case of the editor failing by trying to parse too many Windows include files through recursion. My plan is to prevent WinFBE from parsing the Windows Include files because I will create a set of pre-parsed Windows api files that will load depending on whether UNICODE is active or not. Sorry that the editor is blowing up currently with certain api files.

I will run more tests on this tonight because it appears that it is getting into an endless loop rather than it being a recursion issue.

[Paul Squires]

Hi Paul.
When I try to open a *.bi file from "C:\FreeBASIC\inc\win" location, few of them do not open. The editor is "Not Responding".

I am pretty sure that this is a case of the editor failing by trying to parse too many Windows include files through recursion. My plan is to prevent WinFBE from parsing the Windows Include files because I will create a set of pre-parsed Windows api files that will load depending on whether UNICODE is active or not. Sorry that the editor is blowing up currently with certain api files.

I will run more tests on this tonight because it appears that it is getting into an endless loop rather than it being a recursion issue.

I finally figured out the problem. The fixes will be in the next round of GitHub updates. I have also changed the entire way of handling internal data that is found during the parsing of the source code files. Created a simple data handling source code file called modDB.inc that will be included in the next update. No more using the clsFastHash.inc code.

[Paul Squires]

GitHub updated with latest code. Many, many, many internal changes with this version. Next step is to modify the parser more and in particular, to identify DIM'd variables so that I can present popup autocomplete listbox selector for TYPE elements.