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

[Kuan Hsu]

Dear xbgtc:

PaulSquires has already explained why the shortcut keys designed, and if you insist on using F5 for Quick Run, WinFBE is open source (GPL v3), why not compile a version of your own?

Tip: modMenus.inc

[xbgtc]

> but maybe something i have to get used to or maybe there's an option to turn it all off but anyway.

Yes. In the Menu Options --> Environment Options, you can choose what you want to enable or disable. For example, uncheck Enable Autocomplete.

> i never use F5 and ALWAYS 'quick run' for testing while the code is put together and finally 'compile' once the game or app is finished.

If finally the code is going to be compiled, there is not any advantage in what you are doing.

Thanks for the tip!

and finally, YES but i also paste code from the FB forum or example code quite a bit as well as open new windows in the editor to write test code to see if it works and quick run will run it without having to save first but anyway i just wondered why quick run was not assigned a main key as FBIde was but i guess you can't compare it with WinFBE as WinFBE is quite an elaborate editor and as Paul explained keys were already assigned and quick run was only added after user requests :)

[xbgtc]

Dear xbgtc:

PaulSquires has already explained why the shortcut keys designed, and if you insist on using F5 for Quick Run, WinFBE is open source (GPL v3), why not compile a version of your own?

Tip: modMenus.inc

I'm not insisting on anything and accepted Paul's response but prior responses by others didn't really answer the question.

And i wouldn't know how to compile all that lol but yeh :)

[miilvyxg]

Should there be a new version? It has very silent for a while.

[zelda64bit]

Code autocomplete will be added in a future version. By the way, I like your ide

[miilvyxg]

Code autocomplete will be added in a future version. By the way, I like your ide

What are you talking about? This IDE already has code completion.

[zelda64bit]

What are you talking about? This IDE already has code completion.

If it is automatic, it does not work for me, if it is with a combination of keys tell me what keys, because I do not know.

[miilvyxg]

What are you talking about? This IDE already has code completion.

If it is automatic, it does not work for me, if it is with a combination of keys tell me what keys, because I do not know.

Don't know why. Because it works for me.

[lansn]

What are you talking about? This IDE already has code completion.

If it is automatic, it does not work for me, if it is with a combination of keys tell me what keys, because I do not know.

Don't know why. Because it works for me.

Yes, it had code completion, but WinFBE x32 often doesn't work properly on win10 x64 OS , WinFBE x64 is ok. There is a other problem that when WinFBE x64 start if open many files, it will be crash.

[miilvyxg]

If it is automatic, it does not work for me, if it is with a combination of keys tell me what keys, because I do not know.

Don't know why. Because it works for me.

Yes, it had code completion, but WinFBE x32 often doesn't work properly on win10 x64 OS , WinFBE x64 is ok. There is a other problem that when WinFBE x64 start if open many files, it will be crash.

Why someone ever think about running a 32 bit app on an 64 bit OS when the 64 bit version of the app available? I don't understand.

[jj2007]

Why someone ever think about running a 32 bit app on an 64 bit OS when the 64 bit version of the app available? I don't understand.

Because it's smaller or faster?

[miilvyxg]

Why someone ever think about running a 32 bit app on an 64 bit OS when the 64 bit version of the app available? I don't understand.

Because it's smaller or faster?

Smaller, yes, but only a bit. The MinGW compiler pack is not small. Faster? No. I was taught that 64 bit always has better performance and somewhat confirmed myself that WinRAR 32 bit on Windows 64 bit is slower than WinRAR 64 bit.

[PaulSquires]

I have (finally) resumed work on a new version of the WinFBE editor. I have lots of quality of life improvements that need to be implemented based on my accumulated notes over the past number of months. One thing that I want to disclose here is that the manner in which the compiler toolchain is handled will change. You can now specify as many FBC toolchains as you wish. The only caveat is that each toolchain *must* reside in a subfolder named "Toolchains" that must exist off of the the main WinFBE editor folder. This may seem arbitrary but it does allow for a much easier experience for WinFBE to handle multiple toolchains. Granted, I expect that the number of users who experiment with multiple toolchains will be small but at least now the option exists within WinFBE itself to handle and be able to comfortably switch amongst multiple toolchains. This may (or may not) replace the need to use deltarho[1859]'s fine plugin SetCompilerPaths.

Here is a screenshot (WinFBE will give a warning message if any of the toolchain paths contain spaces as spaces cause WinFBE's compile process to choke when creating process to compile the user's source codes).



I am also hoping to give WinFBE a better look and feel. Over the last many months I have done a fair amount to web programming and using tools like VSCode has spoiled me with the dark themes and clean design. To that end, I will endeavour to modify WinFBE such that themes work better throughout the entire UI of the editor. As a start, I have already added an option to increase the spacing between lines in the editor so that text does not look so cramped together.

Lots of work remains to be done but hopefully I can chip away at it and get a release out sooner rather than later. I know it has been a long time between releases... no need to remind me of that. :-) (These days I use Linux about 95% of the time rather than Windows)

[srvaldez]

glad to see you back Paul :-)

[Arachnophilia]

Hello Paul

I gladly join you.