SetCompilerPathsII & SetCompilerSwitches for WinFBE

[deltarho[1859]]

SetCompilerPathsII

Version II is a port to FreeBASIC of the original version written using PowerBASIC.

Paul Squires wrote a similar tool very quickly, he writes at a blazingly fast speed compared to me, but it fell short of what I wanted. I then had to decide whether to develop Paul's work or port mine to FreeBASIC. I was better acquainted with my work so I went with mine.

Paul's compiler description is a fixed length so anyone wanting to 'ramble on' a bit will get clipped. On opening all the radio boxes are unselected and I wanted the compiler currently in use to be selected.

My original version catered for four pairs of compiler paths and that was increased to six. If we only had three in our ini file then three radio buttons were shown as 'Empty'. Paul's code showed only the number of pairs in the ini file. I took that idea on board. There was some interesting techniques in Paul's code and I made some use of them as well so the credit for this application should go to myself and Paul Squires.

So why did I bother? Version II is high dpi aware - my original version was not. With Paul's 4K monitor my form looked like it was in the early stages of falling into a black hole. I don't have access to greater than 96 dpi but since I am using WinFBX and CWindow.inc by José Roca then high dpi aware is assured.

The ini file no longer has "WinFBE" as the initial string. Here is an example ini file.

Code: Select all

"E:\Downloads\WinFBE_Suite\Settings\WinFBE.ini"
"5.2", "C:\Program Files (x86)\FreeBASIC\fbc.exe", "E:\Downloads\FreeBASIC-1.07.0-win64\fbc.exe"
"7.4", "E:\Downloads\FreeBASIC-1.08.0-win32\fbc.exe", "E:\Downloads\FreeBASIC-1.08.0-win64\fbc.exe"
"8.3", "E:\Downloads\fb108-win32-gcc830\FreeBASIC-1.08.0-win32\fbc.exe", "E:\Downloads\fb108-win64-gcc830\FreeBASIC-1.08.0-win64\fbc.exe"
"9.2", "E:\Downloads\fb108-win32-gcc920\FreeBASIC-1.08.0-win32\fbc.exe", "E:\Downloads\fb108-win64-gcc920\FreeBASIC-1.08.0-win64\fbc.exe"
"10.0", "E:\Downloads\FreeBASIC-1.07.1-win32\fbc.exe", "E:\Downloads\FreeBASIC-1.07.1-win64\fbc.exe"

which looks like this.



This is what a two compiler set up looks like.



A longer description may look like this - but I doubt it.



Paul added some code to WinFBE to allow my tool to work and that will be included in the next release of WinFBE. In the meantime you can get a copy of just the revised WinFBE32.exe and WinFBE64.exe here.

Drop SetCompilerPathsII.exe and SetCompilerPathsII.ini into WinFBE's UserTools folder.

Now go to 'Tools/User Tools...' and complete the form exactly as follows.

If you type into the 'Tools Name:' edit box this populates the box on the far left simultaneously.

Make sure that you look all over the form, there are some entries needing attention at the bottom right.



You are now good to go.

SetComPilerPathsII uses 'Tahoma, 8'. If you rename the exe to SetComPilerPathsIIL.exe, that is with 'l' or 'L' at the end of the filename, then you will get 'Tahoma, 12' provided also that the command in the 'User Tools' form has 'l' or 'L' at the end of the filename. I actually use the 'L' version.

Like this.



You may have seen me getting into a 'right state' at the end of last week writing this and thanks to José Roca and Paul Squires I managed to see the light at the end of the tunnel and eventually a blue sky above. I could have posted this late last Friday but decided to 'kick it around' over the weekend to make sure that it was in a release state.

Thanks to José's teachings I have only used Cast once and that was his recommendation. [Grasshopper]

Download: SetCompilerPathsII.zip

######################################################################################

SetCompilerSwitches

In WinFBE's Compiler Setup we have

'Additional compiler option switches (optional)'

It is easy enough to edit that and they will be used at the next compilation. However, if we want to test a bunch it can be tedious to keep opening that form. On the other hand with SetCompilerSwitches we can quickly change from a preset list like this.



If the last set of switches used is one of your presets then the corresponding radio button will be selected when SetCompilerSwitches opens. If no match is found then the last set used is not one of your presets and no radio button will be selected.

Here is an example ini file. (SetCompilerSwitches.ini)

Code: Select all

"E:\Downloads\WinFBE_Suite\Settings\WinFBE.ini"
"-gen gcc -Wc -O1"
"-gen gcc -Wc -O2"
"-gen gcc -Wc -O3"

As with SetCompilerPaths this tool is high dpi aware and add 'L' for a larger font size, as I have done in the last image.

This is how my WinFBE now looks.



Download: SetCompilerSwitches.zip

[Arachnphilia]

Hello David

..... very nice. Thanks!

[deltarho[1859]]

We have a little problem.

Suppose we opened WinFBE and WinFBE's ini file had 10.0. The config file would be read and 10.0 would now be in RAM. Suppose we ran SetCompilerPaths and changed the compiler to 7.4, for example, the ini file would be changed to 7.4. If we now loaded a bas file and compiled it then WinFBE woud read the ini file again, with the recent edit to WinFBE's code.

We should expect that 7.4 to be used but it isn't - 10.0 is used.

It seems that when the bas file was loaded the values in RAM are flushed to the ini file and since 10.0 was in RAM then it would be used.

On the other hand if we changed to 7.4 after the bas file was loaded then 7.4 would be used, and we would have 7.4 in both the ini file and in RAM. All further compilations would, of course, use 7.4.

If we changed the compiler again and then loaded another file we get the same issue.

This behaviour is replicated with SetCompilerSwitches.

So if we want to change a compiler path or set of switches we should do so only after any file is loaded.

I cannot think why the ini file is flushed on loading a file.

I shall mention this to Paul Squires.

[PaulSquires]

I bet that maybe you are changing the compiler path and then going into the Environment Settings dialog and then closing it.... and then finally loading and compiling your program? When you close the Environment Settings dialog it writes out the ini thereby overwriting the ini change that you would have already made. The fix would be or me to re-read the WinFBE ini prior to showing the Environment Settings dialog.

I will post an updated exe for you to test.

[PaulSquires]

Try the new EXE's in this archive.....

https://www.planetsquires.com/files/WinFBE_20190924.rar

[deltarho[1859]]

I bet that maybe you are changing the compiler path and then going into the Environment Settings dialog and then closing it....

No, I am not doing that. Revised exes make no difference.

Here is an example of what I am doing.

1) Open WinFBE.
2) Open SetCompilerPaths and change from 8.3 to 5.2, for example.
3) Close SetCompilerPaths
4) Load a file into WinFBE.
5) Open SetCompilerPaths

We will see that our chosen 5.2 has been overwritten with 8.3.

All that I have done between steps 3) and 5) is load a file.

If I did not load a file and compiled again then 5.2 would be used.

[PaulSquires]

Thanks David - I am investigating.... I can reproduce based on your steps. Let me see what is going on behind the scenes.

[PaulSquires]

1) Open WinFBE.
The WinFBE ini file is read into memory.

2) Open SetCompilerPaths and change from 8.3 to 5.2, for example.
The WinFBE ini file ON DISK is updated with the change. The data in WinFBE's memory still remains as the old version.

3) Close SetCompilerPaths
Nothing happens to the ini file obviously.

4) Load a file into WinFBE.
Because a new file is opened into the editor, the Most Recently Used (MRU) list is updated. That list of MRU items is then saved to disk into WinFBE's ini file. This also writes the old compiler settings as well unfortunately.

5) Open SetCompilerPaths
The old values are re-read.

I will see what I can do to fix this. Maybe I will use Windows to notify WinFBE when the ini file changes and then automatically re-load the ini file. Let me think about the best way to handle this.

[deltarho[1859]]

Hi Paul

Just my two cents but if you used WritePrivateProfileString to target specific sections of WinFBE's ini file then sections not targeted would remain intact.

[PaulSquires]

Hi Paul

Just my two cents but if you used WritePrivateProfileString to target specific sections of WinFBE's ini file then sections not targeted would remain intact.

That's two cents well spent {smile}
I have implemented the changes using WriteProfileString and it appears to be working well.

Here is the new download.
https://www.planetsquires.com/files/WinFBE_20190925.rar

[deltarho[1859]]

We have a little problem.

We don't now.

Thanks Paul.

Just to clarify: When we use either of the above tools to make a change then that change will hold whether we load a file into the editor after or not.

[deltarho[1859]]

Instead of supplying a path to WinFBE's ini file as the first string of our ini file I have been looking at

Code: Select all

"../Settings/WinFBE.inc"

However, WinFBX's AfxFileExists or FB's FileExists in "file.bi" do not accept relative paths.

I have been searching MSDN for an API to convert a relative path to an absolute path and tried a couple of APIs, but they do not do what I want.

Any ideas?

We are OK as we are - I was just trying to make it easier to create our ini file.

[PaulSquires]

I think a problem would be if your Tool is not installed directly in the \Tools folder. WinFBE tools can be located anywhere on the computer so using a relative path in the ini would be problematic.

However, if a requirement of your tools is that they reside in the Tools subfolder then you simply need to call AfxGetExePathName and replace the "\Tools\" portion of the string with "\Settings\WinFBE.ini". In this case you wouldn't even need to specify the WinFBE ini location in your tool's ini file at all. I think that should work. I haven't tested any of this - I am thinking as I'm typing.

[deltarho[1859]]

However, if a requirement of your tools is that they reside in the Tools subfolder ...

It is from the opening post instructions "Drop SetCompilerPathsII.exe and SetCompilerPathsII.ini into WinFBE's UserTools folder.". I don't provide an opportunity to think otherwise. When the 'UserTools' folder is opened for 'dropping' we see your asciichart32 and GUIDgen32 so I am hoping no one would start to think about using another location. If anyone wants to use another location then I can write versions for them but I shouldn't think anyone will - 'UserTools' is the obvious location to use.

Your text replacement is working fine for SetCompilerPathsII but something is misbehaving with SetCompilerSwitches so I won't be publishing updates until I can fathom out exactly what is going on. I am in the age-old position of comparing code and finding no difference. Very often a walk in the local park, start comparing again on returning and the difference jumps out in seconds.

As Arnie said "I'll be back"

[deltarho[1859]]

It is pouring down outside so no local park. Put the kettle on, made a cup of tea, put my feet up and caught up with the news on the 'telly'. Came back to the code and the break worked, as usual.

OK, forget about the first string of our ini file being WinFBE's ini path.

I have not overwritten the links in the opening post but put both tools into one zip. Chances are that only a few of you will be interested in SetCompilerPathsII but hang onto it, in the future we may see a fbc release with more than one gcc build.

Thanks, Paul - who needs fancy Windows APIs - if there is one to do this.

Download: Both tools

BTW, I am using WString. I see that both you and José are fully committed to using CWSTR. I need to 'up the ante' - it makes life a lot easier.