WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V3.1.0 June 4, 2023)

[PaulSquires]

Any chance of getting Bold and Italic settings on fonts?

Hi Jonge,

Yes, in the next version you will be able to set Bold, Italic, and Underline for the following elements:
- Comments
- Keywords
- Line numbers
- Operators
- Preprocessor
- Strings

[Jonge]

Nice. Is there a way to import settings from a previous version of WinFBE? Or is it safe to just copy the old "WinFBE.wfbe" from a previous copy of WinFBE?

[PaulSquires]

The WinFBE.ini (not the "WinFBE.wfbe" that you posted) configuration file (found in the Settings subfolder) is read with WinFBE starts. You can copy your existing WinFBE.ini to that folder and then start WinFBE. The only thing that you will have to fix are the editor's colors. The current version of WinFBE looks for a section called "THEMES" and if none are found then it creates two themes by default... (1) Default Theme which is a light color, and (2) Visual Studio Code (Dark) which is a dark color theme. You can create new themes based on either of those themes but you can not delete the first theme (Default Theme).

I will upload a new version tonight with the Import Themes support and the Bold, Italics, Underline support for certain code editor elements.

[PaulSquires]

Version 1.5.2 (September 4, 2017)
- Added: Import theme from external disk file (unicode or ansi).
- Added: Able to set Bold, Italic, Underline fonts for code editor elements: Text, Comments, Keywords, Line numbers, Operators, Preprocessor, and Strings.

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

[MrSwiss]

Not sure it belongs here:
A problem, related to José 's CWindow.inc -- file (one of its includes, more like):

AfxCtl.inc -- containing wrong include path:

Code: Select all

#include once "Afx/windowsxx.bi"    ' "win/windowsxx.bi" -- MrSwiss -- 2017-09-05

The test was: a quick-run of "Generic CWindow Template", after the fix above, it at least compiles/run's.
WinFBE ver. 1.5.1, bad news ... for CWindow stuff.

[Josep Roca]

> WinFBE ver. 1.5.1, bad news ... for CWindow stuff.

Not at all. You're using includes modified to compile the editor instead of the official ones, downloadable at:
http://www.planetsquires.com/protect/fo ... pic=4073.0

[PaulSquires]

I had to modify the include because the "windowsx.bi" file that ships with FB is broken. In order to compile WinFBE you would need the replacement "windowsxx.bi" version. (notice the double "xx"), or you could replace the windowsx.bi that ships with FB with the contents of my windowsxx.bi file.

FYI - I am creating a modern looking treeview/listbox style control and a new tab control in order to replace the standard Windows treeview/tabcontrol that WinFBE now uses. This will allow for an incredible amount of flexibility when it comes to color customization. It will also give the editor a much more modern look and feel that may be appealing for some users. Of course, the source code for these controls will be included as part of the package so people interested in understanding how custom controls are written using the WinAPI will find it somewhat educational (I hope).

[MrSwiss]

@José,

> Unrar the Afx folder in the "inc" folder of your compiler(s).

Not such a brilliant idea, if (like me) one run's multiple compilers:

• - 0.24.0 32bit
  - 0.90.1 32bit
  - 1.05.0 32bit (current PRODUCTION)
  - 1.05.0 64bit (current PRODUCTION)
  - 1.06.0 32bit (current DEV ver.)
  - 1.06.0 64bit (current DEV ver.)

I prefer, to have all of it, in one place only (WinFBE).
I also think it to be confusing, mixing Editor (build stuff), with what's supposed to be PRODUCTION.

Another issue is to download it again (if its in the Editor Distribution).
Why .rar?? use .7z or .zip (it's Windows only, after all).

[Josep Roca]

> I prefer, to have all of it, in one place only (WinFBE).

I would also prefered it, but there are incompatibilities between the FB headers for 32 and 64-bit, at least in the GDI+ headers.

> I also think it to be confusing, mixing Editor (build stuff), with what's supposed to be PRODUCTION.

They are separate projects developed by different individuals at his own pace. It happens that Paul uses a slightly modified version of the framework to build the editor. I knew that this was going to cause some confusion. Maybe Paul should warn that the Afx folder of the editor's source code is not intended to run my examples.

> Why .rar?? use .7z or .zip (it's Windows only, after all).

Why not? It is a matter of preference. Anyway, it will probably end being hosted at GitHub.

[MrSwiss]

> ... but there are incompatibilities between the FB headers for 32 and 64-bit, at least in the GDI+ headers.

Thanks for clearing that up. Can't that be solved with "conditional compiling" ?
Preprocessor code, to be more to the point? >> #Ifdef __FB_64BIT__

> I knew that this was going to cause some confusion.
> Maybe Paul should warn that the Afx folder of the editor's source code is not intended to run my examples.

Ohh, yes, definitely a good idea, because, after installing a IDE (any one):
- user is usually trying to run examples provided (which then all fail, to compile/run!).
One of the best ways to make, especially beginners, to "flee, the sinking ship", immediately.
(And, probably forever, too.)

> Why not?

Windows OS has .zip native, automatically ... but, no .rar (not just a matter of preference, IMHO).

[Josep Roca]

> Thanks for clearing that up. Can't that be solved with "conditional compiling" ?
> Preprocessor code, to be more to the point? >> #Ifdef __FB_64BIT__

I'm already using conditional compilig:

Code: Select all

#ifdef __FB_64BIT__
    #inclib "gdiplus"
    #include once "win/gdiplus-c.bi"
#else
    #include once "win/ddraw.bi"
    #include once "win/gdiplus.bi"
    using gdiplus
#endif

I have been thinking about it and I think that I have found the solution to only have a copy of the framework that also could be placed anywhere. This will require a change in the WinFBE editor:

The "Compiler Setup" will require the addition of a new entry to set the path of the framework (by default, if the user does not change it, it will be <drive:><\editor folder>\src") and the editor will pass it to the compiler using the -i option. I have tried it adding "-i C:\Users\Pepe\WinFBE\src" to the "Additional compiler switches" and it works. This will allow to compile the examples using the Afx folder used by the editor (if the user unzips the "src" folder) without having to download and install the framework separately, making the process very beginner's friendly.

There is still the problem of the broken "windowsx.bi" file. If we modify AfxCtl.inc to include "windowsxx.bi" instead of "windowsx.bi" it works, but if "windowsx.bi" is also included directly or indirectly, there will be conflicts. Maybe we can take the risk until Free Basic will make available a new one.

[MrSwiss]

> I have tried it adding "-i C:\Users\Pepe\WinFBE\src" to the "Additional compiler wsitches" and it works.

Exactly, what I've done, too.
That's when I've discovered the "Path" issue, with AfxCtl.inc, to include "windowsxx.bi".

> Maybe we can take the risk until Free Basic will make available a new one.

Yep, I think so, too ... (it's only a small change, anyway).

[Imortis]

Maybe we can take the risk until Free Basic will make available a new one.

What exactly is the problem with the header? I can fix it and submit it.

[MrSwiss]

What exactly is the problem with the header? I can fix it and submit it.

For this issue, it's already fixed (by PaulSquires).
The problematic header is "windowsx.bi", the fixed one is "windowsxx.bi" -- NOTE: [xx] twice, renamed.

Its all part of WinFBE / CWindow combination (Paul Squires / José Roca).

[St_W]

What exactly is the problem with the header? I can fix it and submit it.

see:
https://freebasic.net/forum/viewtopic.p ... 04#p231604
https://freebasic.net/forum/viewtopic.p ... 77#p234877
https://freebasic.net/forum/viewtopic.p ... 3&start=45

I've created a branch with the fixes some time ago:
https://github.com/swurzinger/fbc/commits/header_fixes

but there's still incomplete and ideally the scripts should be modified to generate the headers correctly in the first place.