bgracontrols icon indicating copy to clipboard operation
bgracontrols copied to clipboard

V2 SuperGauge, breaking changes with V1. Update Spinner Test program

Open sganz opened this issue 7 months ago • 1 comments

Updated SuperGauge to V2. Included a lot of additional features, property name clean up (Some breaking changes here), as well as a V2 test program with a lot of the new featured incorporated as well as a bunch of presets for easy testing of many features.

In addition the SG V2 support Auto Scaling if the option is enabled, that is, if enabled will deal with High/Low DPI settings and resize all components of the gauge properly (or so I hope!).

A couple of minor changes to the test program on the SuperSpinner got in as well.

Let's see how this goes :)

sganz avatar Jun 11 '25 21:06 sganz

Thank you very much. If someone is available to review the changes, feel free to jump in. Today I can't do the review. I will check back in the coming days.

circular17 avatar Jun 14 '25 19:06 circular17

Hi, I can't compile BGRAControls else I will be prepared to test...

lainz avatar Jul 05 '25 15:07 lainz

Is it something related to the V2 Gauge? I can wipe my local code and pull the branch and see if it works if that helps and fix anything on my end. I'm on Windows if that matters

sganz avatar Jul 05 '25 17:07 sganz

Here is the issue https://github.com/bgrabitmap/bgracontrols/issues/246

Basically it relates to mouse and key input package.

lainz avatar Jul 05 '25 19:07 lainz

Hi @sganz , I can't compile your test project because it requires uEcontrols.

lainz avatar Jul 09 '25 22:07 lainz

I think all the other test programs I did had the uEcontrols LED component as well, for sure the original v1 of supergauge did, as well as the spinner test. Has something changed or is it that you can simply add the package to get it to compile? I don't think it's anything in the SuperGauge V2 code, just the test program.

I could swap out the uELed, but would rather not until the build is working as before, then I can redo the Spinner and the Gauge code with the BGRA LED, and I think that it's on my list to 'enhance' as it's sorta' not LED looking like the uEcontrols version which is using BGRABitmap so a good thing ;)

sganz avatar Jul 10 '25 00:07 sganz

Control doesn't look good on High DPI: Captura de pantalla 2025-07-10 144343

lainz avatar Jul 10 '25 17:07 lainz

Click the button on the Basic Tab for AutoScale.

What are your HighDPI settings? I run also on Windows with HighDPI and a scale factor of 150% and if you go between HighDPI with 100% you it should work, but if you compile with HighDPI Scaled and change scaling you for sure will need to have the 'AutoScale' option checked.

Let me know you Lazarus configuration and your Windows Resolution and Scaling and I'll see what's up.

Thanks for getting it going, and as soon as this is all good I'll work on a solution to get rid of the ueControls as it's only using the LED. Oddly I use the BGRA Shape control that is almost a replacement for the ueControls LED and can keep all the code in the BGRA relm.

Sandy

sganz avatar Jul 10 '25 19:07 sganz

So a quick test and I get the same results but it's what the scaling issue, it may be something as simple to set the default action of the gauge to 'AutoScale' to true.

If you check the Auto Scale Checkbox on the Basic Tab it should make it work OK.

image

It's a tricky thing, as design is pixel perfect but if you enable Auto Scale the design may not be what you think it really is if you want no scale, pixel specific sized gauge I opted to make Auto Scale not default. I guess it depends on how you want to use the gauge.

I think the issue is the LCL is scaling the overall component in this case from 300x300 as designed to 200x200. So if the Auto Scale is set, it's not as per designed (some things are based on the component size like the outer bezel/frame but that's all).

Someone sent some code to force disable the LCL's change of component size when HighDPI scaling is doing it's magic, but I think that may not be the right way to go. So I chose a middle approach.

So the options are

  1. Default AutoScale to Enable at some pain/inaccuracy in the design (under some circumstances, not sure of them all)
  2. Default AutoScale to Disabled for design time accuracy (again possibly only under HighDPI, not sure of all the combination)
  3. Leave the gauge as is, and just set the Gauge in the test program to Auto Scale Enabled so it always works.

Thoughts?

And again, please send me your display resolutions (single display I'm assuming) and if your IDE has the Force DPI option checked. This may be also affecting design as changing to 100% Scaling on 4k res on windows will also make the gauge scale and look bad in the design time form editor.

image

sganz avatar Jul 10 '25 19:07 sganz

Thanks, yes with that property works fine.

lainz avatar Jul 11 '25 15:07 lainz