drWinFBE_Tools

[deltarho[1859]]

drWinFBETools.zip (203KiB)

The above unzips to drWinFBETools folder which includes drWinFBE_Tools.chm, ArchSettings.exe, Registers.chm, SetCompilerPathsII.exe, and SetCompilerSwitchesII.exe.

The exes are the latest versions of user tools for the WinFBE IDE by Paul Squires. The original Help file is now deprecated and that thread points to this one.

Note: 16 Feb 2024

The zip no longer includes SetCompilerPathsII.exe, but does include DlgMsgBox.dll.

Note 27 Feb 2024

The zip no longer includes ArchSettings.exe.

[PaulSquires]

Thanks - I'll be sure to put these most up to date versions in the next WinFBE Suite update.

[deltarho[1859]]

I'll be sure to put these most up to date versions in the next WinFBE Suite update.

The latest versions of WinFBE have no User Tools installed and there is nothing in 'WinFBE Editor Help' mentioning tools. So, anyone who comes to WinFBE for the first time would not know where tools exist and even if they did they may find it a struggle 'installing' them as there are no examples to look at.

If you included drWinFBETools.zip in your distribution, which includes drWinFBE_Tools.chm, then they will not only be in a position to 'install' some, if not all, of my user tools without going anywhere near the 'User Tools' form but also your user tools as I explain how to 'install' them as well.

I also mention, in the latest Help file, where to get the gcc toolchains 8.3 and 9.2 if anyone wanted them because they have not been available since version 1.94, after which the assets dropped from 5 to 3. Again, anyone who comes to WinFBE for the first time would not know that they existed. Come to think of it if anyone has been using WinFBE for some time and 'jumped over' 1.93 and 1.94 they may not be aware that the 'out of the box' WinFBE is no longer using gcc 8.1 but gcc 5.2. They should but some folk are not that observant.

If you are not happy with including drWinFBETools.zip in your distribution then mention this thread, and what it does, in your GitHub updates. I very much doubt anyone who comes to WinFBE for the first time in the future will immediately jump to this thread as it drops out of sight.

[deltarho[1859]]

There is something which I forgot to mention in the new Help file. I will correct the omission but in the meantime ...

If we append to the filename of SetCompilerPathsII.exe and SetCompilerSwitchesII.exe either 'l' or 'L' and the corresponding entries in the [UserTools] section of WinFBE.ini in the Settings folder then a larger font size is used for those whose eyesight is not as good as it once was.

Comparison for SetCompilerPathsII and SetCompilerPathsIIL and similarly for SetCompilerSwitchesII and SetCompilerSwitchesIIL

[deltarho[1859]]

Both SetCompilerPathsII and SetCompilerSwitchesII have been updated. If they are running when WinFBE closes then they will close as well.

The opening link now includes the new versions.

Thanks to Josep Roca and jj2007 who both threw me a lifebuoy whilst I was sinking fast.

[deltarho[1859]]

The opening link now includes references to the last two posts in an updated Help file.

I reckon that is me done, for a while at least, with regard WinFBE user tools - to be honest I am fresh out of new ideas. Paul has gone quiet - we haven't had an update in seven days.

[PaulSquires]

The opening link now includes references to the last two posts in an updated Help file.

I have downloaded your latest zip and have it ready to go for the next WinFBE release. If you tweak it any further then just let me know and I'll update it.

Paul has gone quiet - we haven't had an update in seven days.

Lol, I have an update close to being ready. Just need to work on the copy/paste of visual designer controls because it can be a little quirky at times.

[deltarho[1859]]

When SetCompilerSwichesII was written it did not require a change in the format of SetCompilerSwitches.ini so the latter kept its name. This was a bad move and has led too confusion.

With WinFBE 2.1.5 I had a choice of either asking you to rename SetCompilerSwitchesII.ini to SetCompilerSwitches.ini or update SetCompilerSwitchesII.exe to look for SetCompilerSwitchesII.ini and not SetCompilerSwitches.ini. Clearly the sensible thing to do was to update SetCompilerSwitchesII.exe and that has been done, to v 1.03.

The last Help file introduced a fast method of 'installing' User Tools. Paul came up with a better method with WinFBE 2.1.5 - "Running WinFBE for first time with no existing WinFBE.ini config file will automatically create entries for User Tools that exist in the Tools folder."

drWinFBE_Tools.chm required a re-write. Oh, dear! Being allergic to writing Help files, Paul has the same malady which, it seems, is worse than mine, I consulted my Doctor, and she said I should be OK without a change in medication and was pleased to hear that the resulting Help file is smaller than the last one.

The zip in the opening post now has SetCompilerSwitchesII.exe (V 1.03) and the new help file.

[PaulSquires]

Oh, dear! Being allergic to writing Help files, Paul has the same malady which, it seems, is worse than mine, ...

Lol, yes, most definitely :-)

I'll update the next WinFBE release to include your updated files.

[UEZ]

The Cpaths is a very good idea and very useful but I don't like the separate window which is topmost.

@PaulSquires: can you put it as a dropdown menu just right next to compile dd list?

Thx.

[deltarho[1859]]

The Cpaths is a very good idea and very useful but I don't like the separate window which is topmost.

Hmmm!

If you have a look at 'My set up' in drWinFBE_Tools.chm you'll see that both Cswitches and Cpaths "are in a 'gutter', created with the edge margin, beyond which we will not code, and they are not in the way of the Find/Replace box."

The reason for TopMost is so that we can scroll up and down our code and the CTools remain fixed and visible.

However, if you don't like that then you don't like it. What you can do is to have 'Action:' 'Invoke only when selected by user' - the window pops up, you select a compiler, and then close the window.

Selecting a compiler via a drop down menu is a good idea, like the build configuration drop down menu but will need to be greyed out with only one toolchain on board. I may be wrong but I think that the majority of users will not venture beyond one toolchain.

I will be interested to see what Paul says to your suggestion.

[UEZ]

@deltarho[1859]: for sure I know the purpose of topmost style but if you don't work with WinFBE then the window bothers. Imho the more elegant solution is to integrate the functionality to WinFBE directly.
Don't get me wrong, it is not an offense against your code.

[deltarho[1859]]

Don't get me wrong, it is not an offense against your code.

I don't take offence to an honest appraisal.

but if you don't work with WinFBE then the window bothers.

I don't understand that - we get a window when we click on 'Search>Replace...'.

[UEZ]

I don't understand that - we get a window when we click on 'Search>Replace...'.

If I start WinFBE then it looks like this here:



If I switch to another window (app) then I can still see the Cpaths window on top of that window. I need to move it away or minimize it manually from the task bar.

[deltarho[1859]]

@UEZ

Ah, I am with you now.

The cPaths window, on Windows 10, is not wide enough to accommodate a title and a minimize button and so on.

I have two monitors - I could be coding on one monitor and checking out an API at MSDN on another.

Anyway, why don't you just close cPaths? You can always open it again - there is no information to lose and it opens quickly.

I could add a function to toggle between topmost and not topmost - would that be any good?

Why do you have cPaths positioned so high? It gets in the way of the Find window.