drWinFBE_Tools

[deltarho[1859]]

If anyone is watching this saga. Both fxm and I use Firefox.

I switched to Chrome, and we are now having a conversation - my Replys are working. Switched back to Firefox and Replys are not working.

I got an update to Firefox yesterday and could not type into the address bar. Opened my text editor and could type. That lasted for a few hours. It looks like Firefox corrected it and sneaked another update in but kept quiet about it.

Anyway, if the Reply continues to fail in Firefox the workaround is to start a new conversation rather than Reply.

I don't use PMs that much, so I am not that overly bothered. Replying is useful when both parties Reply as the conversation can be viewed.

Thanks fxm.

[Arachnophilia]

Hello David

I have received the PM from fxm.
I couldn't miss the notification signal either.
The e-mail notification has also arrived.
I have no idea where your PM has gone.
I also use the current version of Firefox.
Thank you fxm, too.

[fxm]

Switched back to Firefox and Replys are not working.

I also use the current version of Firefox.

I am also using the latest version of Firefox ("123.0 (64-bit)") and everything is fine for me.

[deltarho[1859]]

@fxm

I tried another Reply late last night. The Outbox showed (1) and was clear this morning, so it looks like you received it. The message was 'Further test'. If you got that, then my Reply is working again.

[fxm]

Yes I received it.

[deltarho[1859]]

Weird. I didn't do anything different — I just repeated what I had done earlier.

Thanks, fxm.

[deltarho[1859]]

New version of SetCompilerSwitchesII V1.0.18

Before fbc 1.10.0 the default -arch was 486 and SetCompilerSwitches (SCS) forced 686. This is no longer needed, as 686 is now the default [586 for DOS].

The Arch Settings plugin is now incorrect and no longer supported, to the extent that the Check 3 State Box (-arch) has been removed and all references to -arch from SCS.

If a 64-bit build was in operation we could override that to 32-bit via the -arch box. We have now lost that 'trick' and need to use 'Build Configurations...'.

As much as I like WinFBE I am not a fan of the minimalist menu system of WinFBE 3.0 and above, preferring the pre 3.0 menu system. To get to 'Build Configurations...' requires us to use 'File>Preferences>Build Configuratios...'. Of course, we can use F7 if we can remember it. A new button has been added to SCS 'Build Configurations...'. Click on that and all will be revealed.

'Compiler Setup' is a more lengthy process — 'File>Preferences>Environment Options...>Compiler Setup'. We can use Shift+F7, but that only gets us to 'Environment Options...' and the last selection we made there; WinFBE has a memory. A new button, 'Compiler Setup', will get us there immediately. I should think srvaldez will like that one. I doubt that I am riding roughshod over WinFBE's memory as not many, I reckon, will visit 'Environment Options...' often other than to visit 'Compiler setup'.

So SCS now requires WinFBE 3.0 and above and fbc 1.10.0 and above.

The opening post has the latest SCS and drWinFBE_Tools.chm.

SCS V1.0.18

[deltarho[1859]]

What is it with coding? We don't update for four years and then have an idea. After implementation, we get hit with another idea.

SCS V1.0.19

I miss not having 'Win64 GUI (Release)' almost permanently in force. I rarely write libraries.

Well, it is back with the inclusion of a two state checkbox at the top right of SCS; namely 686.

If the current build configuration is 32 bit, then whether the 686 box is checked or not makes, no difference.

If the current build configuration is 64 bit, then we will get a 64 bit compilation if the 686 box is unticked. If it is ticked, then we will get a 32 bit compilation. How simple is that?

That is with gcc. It is a little different with gas.

If we choose gas and have the 686 box not checked, then we get '… backend is incompatible with CPU, x86-64. That is easily remedied by checking the 686 box.

If we choose gas64 and have the 686 box checked, then we get '… backend is incompatible with CPU, 686. That is easily remedied by unchecking the 686 box.

We had the same issue with gas/gas64 with the previous -arch three state checkbox.

So if you are not writing a library, then you can use 'Win64 GUI (Release)' all the time.

As always, when making changes with SCS don't forget to use 'Apply'. I sometimes forget myself, and I wrote SCS.

Opening post zip updated.

[deltarho[1859]]

SCS V1.0.20

If we choose gas and have the 686 box not checked, then now SCS will check it for us when we click 'Apply'.

If we choose gas64 and have the 686 box checked, then now SCS will uncheck it for us when we click 'Apply'.

There isn't a computer on the planet which can second guess what we meant to do.

However, I am guessing that if you choose gas or gas64, then you meant that so the 686 box is corrected, if needed, to comply with the chosen compiler.

That is much better than the compiler telling us that we got it wrong.

Needless to say, a correction, if made, to the 686 box will carry over to the next WinFBE session.

Of course, if the 686 box was correct, and you picked the wrong compiler, there is nothing that I or your computer can do about that.

Opening post zip updated.

[deltarho[1859]]

Found a mistake in SCS. There is a Select/End Select construct which is repeated. I forgot to update the second one. I should have used a macro. The result of the error could report no preset found, which would be false.

SCS V1.0.21

At the top of our source code, we can add '#Console on, to include code for a console. If we forget to do that and have a GUI build configuration in operation and try to use Print, then we will find ourselves in trouble. Unfortunately, some of us do forget.

To help with that, SCS now includes a checkbox at the very top of its form.

So a checked box will load a console and an unchecked box will not.

There is now no need to employ '#Console on.

The larger form font size now needs some work. That is a laborious task, but I wanted to get the corrected mistake out quickly.

Updated zip in opening post.

[deltarho[1859]]

The larger form font size has been tidied up and looks OK.

Updated zip in opening post.

The Tips and Tricks topic in the Help file has been replaced with simply Tip.

[deltarho[1859]]

Found a bug in SCS.

When we have two forms with a normal font size and a larger font size to facilitate those whose sight is not as good as it was then changing to the larger font size will see Windows trying to resize everything for us.

Unfortunately it is not good at it, so we have to make some adjustments ourselves. In ten places, SCS makes adjustments.

I use 'Win64 GUI (Release)' most of the time, so don't need to use 'Build Configurations…' much. My preference is the larger form font size. When I clicked on 'Build Cofigurations...' I got 'No preset used' and the 'Edit buton' showed an empty command line. Windows was sending a 'Clear' button message.

When I was tidying the large form font size, a 'Copy & Paste' did not change the control ID from 'Clear' to 'Build Cofigurations...'. It was tested using the normal form font size, but not the larger form font size.



Here is a corrected SetCompilerSwitchesII.

Opening post zip has also been updated.