Setting gcc compiler for WinFBE

[PaulSquires]

It doesn't appear that the SetCompilerPaths tool is high dpi aware? I just ran it on my system and everything is squished together and small. Maybe would have been better to have used Jose's CWindow code?

I have also attached a screenshot of a simple User Tool that I set for the utility that can be easily invoked from inside WinFBE by pressing the Ctrl+3 hot hey combination.

[deltarho[1859]]

It doesn't appear that the SetCompilerPaths tool is high dpi aware?

How odd I set it in the manifest with this.

Code: Select all

<asmv3:application>
  <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
    <dpiAware>true</dpiAware>
  </asmv3:windowsSettings>
</asmv3:application>

SetCompilerPaths is written in PowerBASIC and although I have my own manifest I actually used yours via

Code: Select all

#Resource Manifest, 1, "WinFBE_manifest.xml"

Your screen shot is identical to mine except the command is '.\UserTools\SetCompilerPathsL.exe'

[Josep Roca]

> How odd I set it in the manifest with this.

This only disables Windows virtualization, but then you have to scale the size of the controls according to a ratio that is calculated as follows:

Code: Select all

PRIVATE FUNCTION AfxScaleRatioX () AS SINGLE
   DIM hDC AS HDC = GetDC(HWND_DESKTOP)
   DIM rxRatio AS SINGLE = (GetDeviceCaps(hDC, LOGPIXELSX) / 96)
   ReleaseDC HWND_DESKTOP, hDC
   FUNCTION = rxRatio
END FUNCTION

The fonts must also be scaled, although the calculations are different.

CWindow scales fonts and controls automatically.

Of course, you won't notice how awful not DPI aware applications look and behave in a computer using high DPI settings unles you use high DPI settings in your computer.

[deltarho[1859]]

Thanks José. This is not an area that I am well acquainted with.

I have just switched from PB's headers to your headers and added AfxSetProcessDPIAware to PBMain.

@Paul

Try this and then add 'L' to the filename for a larger font. Hopefully, all will be well. Getting close to my sell by date I use 'L'.

SetCompilerPaths.zip

[Josep Roca]

> I have just switched from PB's headers to your headers and added AfxSetProcessDPIAware to PBMain.

This does nothing if you already are using a manifest with <dpiAware>true</dpiAware>.

As I said, this only disables Windows "virtualization". Windows scales non DPI aware applications when running in a computer which uses high DPI settings, although at the cost of fuzzy fonts, artifacts and other problems caused because fonts and GUI elements aren't scaled but Windows creates a bitmap and displays it stretched.

DPI aware applications must disable Windows virtualization by using an appropriate manifest and scale fonts and GUI elements programatically.

[deltarho[1859]]

by using an appropriate manifest and scale fonts and GUI elements programatically.

Flaming heck!

Anyway, my beast recommends a 100% scaling. I have just scaled up to 125% and found that I needed to do some adjustments, so I did that. Going back to 100% the frame is a little wider than I would like it to be, so I see your point.

If anyone is scaling to 100% or 125% then SetCompilersPaths is OK, for the time being. I need to look into this subject more than I have done. I have just uploaded the very last version.

For the hell of it I scaled up to 150% and I get a mess. Having said that I have just run my Encrypternet application at 125% and 150% which uses buttons and a frame and no extra work was required. Hmmm, bit of a nightmare Microsoft.

[Josep Roca]

> If anyone is scaling to 100% or 125% then SetCompilersPaths is OK, for the time being.

And what happens if you're using 175%, like me, or much more if you're using a 4K monitor?

DPI aware applications must scale GUI elements by multiplying the number of pixels by a ratio that depends of the DPI settings and that can be calculated at startup.

> For the hell of it I scaled up to 150% and I get a mess. Having said that I have just run my Encrypternet application at 125% and 150% which uses buttons and a frame and no extra work was required.

But that application uses CWindow, if I'm not wrong, and CWindow does the scaling for you.

> Hmmm, bit of a nightmare Microsoft.

Without serving as a precedent, Microsoft is not to blame this time.

[deltarho[1859]]

Having said that I have just run my Encrypternet application at 125% and 150% which uses buttons and a frame and no extra work was required.

Encrypternet uses CWindow.

José, you posted just before I did.

I used PB's DDT because it is quick for little projects. From now on I will use FB's WinFBX for all my GUIs. Come to think of it I should do the same at PB with your PB WinFBX.

We live and learn.

What I should do is rewrite SetCompilerPaths using WinFBX but the lesson has been learnt and I don't know what Paul has come up with.

Without serving as a precedent, Microsoft is not to blame this time.

Sorry, Microsoft not that anyone there is reading this.

PS I have just run Encrypternet at 175% scaling - perfection! it is more capable than I thought it was.

[badidea]

Sorry, Microsoft not that anyone there is reading this.

Don't worry, if Microsoft invalidates your licence key, you can always switch to GNU/linux.

Don't have any experience with DPI-awareness on linux yet. Switched it off because I don't have a really high-DPI screen and standard font size (e.g. in file manager) is large enough. And in a web-browser to can set any scaling crtl+ / crtl- quickly.

But on Windows (10), it is a real mess I think. Lots of old applications that do not display properly. So I force it all to 100%, but the desktop and file manager fonts are then too small and thin. You can increase the this font size separately, but then you run into other problems. When all the old programs are gone, the problem will probably disappear, but that it take some time. A complication is that 'they' try to make everything 'touch-friendly', witch is waste of screen area (e.g. large buttons) if you are not using 'touch'.

[deltarho[1859]]

Don't worry, if Microsoft invalidates your licence key, you can always switch to GNU/linux.

It is said that "A picture is worth a thousand words". I have just saved nearly three thousand words there - I'm an eco-warrior.

[PaulSquires]

I have a 4K laptop screen on my Dell XPS 15 and run a DPI over 200%. It took me a long time to heed Jose's recommendations about high DPI but now it is all routine for me. Jose's library does all the scaling for you. You just need to be aware of what api functions are returning raw pixel and whether you need to scale it up or reverse it to get the unsxaked value. Every programmer on windows has to know and deal with high dpi these days. Likewise, it took me a while to switch from ANSI to Unicode for everything. Once again thanks to Jose.

[deltarho[1859]]

I should imagine that a few members will not be aware that WinFBE was written using FreeBASIC and José's WinFBX. WinFBX is essentially SDK wrappers. The only problem is that the WinFBX Help file is over 4MB without an image in sight. There is no chance that I will get to grips with a half decent percentage of it. Where José found the time to write the WinFBX Framework and its Help file is beyond me.

@José

My best wishes to Valencia - you have had some pretty foul weather lately.

[deltarho[1859]]

It took me a long time to heed Jose's recommendations about high DPI but now it is all routine for me.

It may take a while for it to be all routine for me but it is not looking that difficult.

I am off topic now but

This snap is at 100% scaling.

This snap is at 150% scaling.

No messy about it has scaled up perfectly.

If my monitor was 144 dpi as opposed to 96 dpi then the second snap would render the same size as the first snap but have a 50% higher definition.

The snaps are of a shell at the moment but is my next tool for WinFBE. Instead of going into 'Environment Options...' and edit we will be able to quickly select a set of switches 'on the fly' since the config file is reloaded before a compilation with the upcoming WinFBE release. I may be gone sometime - I know PB's approach like the back of my hand but not so with WinFBX.

However, this time I am using FreeBASIC, WinFBX and CWindow which, as José pointed out, "scales fonts and controls automatically".

Absolutely flaming magic! Thanks José!

[Josep Roca]

> My best wishes to Valencia - you have had some pretty foul weather lately.

Thanks for your wishes. It has been the heaviest rainfall in more than a century. Oddily, I have been spared: it has rained very little in the town where I live.

[Josep Roca]

BTW the old help file is outdated and discontinued. It had become too big to work with the free version of HelpNDoc that I was using. The latest version of the documentation can be found at https://github.com/JoseRoca/WinFBX/tree/master/docs

It is also incorporated in the WinFBE editor: Menu -> Help -> WinFBX Framework help.