BGRA DTThemedGauge

[SandyG]

Was messing with the 2 analog gauge in the BGRA Controls and came across and odd 'feature' of the the DTThemedGauge.

Seems if resizing the gauge at design time the pointer loses it origin or something. Picture attached. Stays that way when run as well (all on windows 11 Laz3, BGRA 9.03)

Before I start looking at it, was wondering if anyone has seen this. The regular DTAnalogGauge does not have this issue.

Sandy

[SandyG]

Found the issue, did a PR into the dev branch, again not sure if I botched it.

Was a one line change, had a typeo it seems

Code: Pascal  [Select][+][-]

1. //Had drawing line from y to y
2. FPointerBitmap.DrawLineAntialias(origin.CenterPoint.y, origin.CenterPoint.y, x, y, PointerSettings.Color, PointerSettings.Thickness);
3.  
4. // updated, in the PR
5. FPointerBitmap.DrawLineAntialias(origin.CenterPoint.x, origin.CenterPoint.y, x, y, PointerSettings.Color, PointerSettings.Thickness);

Sandy

[lainz]

Thanks.

Question: Do you want to be part of BGRAControls team? If yes send me a PM and I will invite you, so you can manage the pull request..

[SandyG]

I might down the road, still getting my hands dirty with all of this. Let me get some more experience doing more then hack debugging . I'm happy to help in any case.

May add a few features to the Themed Gauge... If I can, and that will help me get some more experience

Likely on my list of Gauge features is something more like a rectangular style gauge (see also attached) like you might see on some of the other industrial control packages (Delphi). Will have to think about how to change things to support that.

Might not be too bad, but haven't had time to look at that yet.

Sandy

[lainz]

Looking good.

I will add you as deveolper, feel free to change the code and make improvements or new controls.

[SandyG]

Just started looking at the ThemedGauge code, a lot looks unfinished/unimplemented or Work in Progress.

The main question is their a reason that the position is an integer? It seems like it should be a float?

Finding that Maximum value for the scale has a property, but no Minimum. Neither are implemented. Only Maximum is a property. Also Angle is not implemented but exposed as a property. [edits]

Looking for a place to start, but for sure the Position I'm thinking must be a float or the gauge operation will have steps because of the integral values.

Any background or history on the Gauge development?

Lastly is the Name 'Themed' the intention, as I know some components are actually themed, or is themed in the case of the gauge meaning 'enhanced'?

Sorry for lots of questions, but want to start in a good direction before playing with some code.

Sandy

[lainz]

Hi, no one knows nothing about these components, try looking the original author in the forums.

[SandyG]

Did some searching and really didn't find much about the history, or really much at all on the Gauge.

I might start with a few simple things to get my feet wet.

Maybe from this list -

• Convert Position to a float
• Remove fixed constants for many things that seem to be in the code that should come from properties
• Add missing properties and try to implement (Angle, min range, etc).
• Add a triangle pointer

The only thing is that in converting the position from an integer to a float should I worry about about previous version compatibility? Can Properties be overloaded to keep compatibility when converting from a integer to a float?  (Need to check out fp specs I guess on this one).

Sandy

[SandyG]

@lainz, @circular

I see some .pp files in the repository, along with the same file with a .pas extension. Should the .pp files be removed from the repo? It seems to cause confusion with Lazarus when editing the .pas file and compiling, and also me.

I see these file as .pp extensions -

• dtthemedgauge.pp
• dtanaloggauge.pp
• dtanalogcommon.pp

Thanks

Sandy

[lainz]

I see. Just delete them maybe these was copied by mistake...

About the value as float... I don't think it will be a big deal but yes published property can go wrong with the change. So change it and update the demo project.

[SandyG]

Thanks,

Will delete the .pp versions.

Once I get a bit more into it I'll try the demo project and make adjustments. Hopefully only minor stuff will have to be updated.

Thanks again!

Sandy

[Josh]

Hi

Just some thoughts.

be careful changing to float, any one using the component, it will break their project, they may not even be able to open their project to fix it.
(single/double as they have a fixed byte size, do not choose a type that is definded dependent on cpu/architecture)

using any float type, can have many bad side effects, if user does a standard comparison for value match they probably will not work.

i would stick with integer/cardinal type, then its up to usr to do any decimal resolution they need. As long as they can overide the displaying of value, so they can choose how the value is displayed, as some may want 0.12300  other may want 0000.123 etc.

props
Min,Max,Interval
-10000,15000,100
Would allow for a display of 250 distinct visual increments.
User could then overide the display as they seem fit, theymight want the value
to be displayed as -10,000 or -100.00 or -10.000 and in Red / 14,999 or 149.90 or 1.4999 and in Blue.

What might be beter is fix any bugs in existing, allowing for display override, then have a DecimalVersion of the Control that inherits the Fixed Control, that does the 'float stuff', that way you have best of both worlds, and any future bugs/fixes to the base control,propogates to the decimal version. that way it should have little to no impact on existing users, but a'new' controlif users need decimal, and it shouldbe easier to maintain.

[SandyG]

Josh -

Thanks for the comments.

Since this is a display control and everything is internally doing floating point, it's going to be just to figure out a way (if possible) to overload the property. Scaling integral numbers IMO is not a great solution, and while possibly more accurate, it's more of a pain to use. Have to think about this.

It's no problem to set the value of a floating point directly from an integer, it's just the reading that has the problem. My guess is most are setting the value of the Gauge, but not reading it, as they already have the value so why read the gauge when you already have it.

It's odd the original author had the gauge as an integer value as it not really going to help performance, and just complicates the display by not allowing the angle of the pointer to be anything it needs to be, and 'notchy' as it works.

Expanding it to have more points to make it smoother, again makes it more complicated to use. The resolution is as accurate as the display will allow. I'm thinking it will be sorta' like the knob where you can set the scale of the gauge and it will do the rest. Internally it's mostly floating to do all the calcs, so not much worry about that aspect of it... well until it breaks something 

Also thinking of decoupling the 'Range' from the scale. It's possible to have a gauge with multiple scales but the scale(s) might not dictate the range of the gauge. Have to think about that.

The Themed gauge as I see it was a work in progress, I think who ever was working on it did a great job in splitting out some of the components (needle, scales, etc) but I think a lot was left incomplete, but it's a very good start.

As to keeping a integer version I think the basic gauge would be good for that, and the 'Enhanced' version (DTThemedGauge) could move away from specifics without much worry. I really will have to see if I can make it compatible but not sure at this point. Have to see if I can overload a property to allow either float or int values. Just have to read the freepascal docs a bit more.

Going to re-read your post a bunch of times too, just to get a solid idea how to make it work as well as allow for it to be more feature complete.

Thoughts in progress!

[lainz]

Maybe you just can create a new component and grab everything you need from the other controls and add your own stuff.

We already have more than one for buttons for example so there's no problem.

[SandyG]

Might be a plan but I think the current gauge is somewhat unfinished, hate to have more redundant components. BUT, I think what I might do is just see how far I can get, and see how compatible it ends up being. If not to far off then likley no new component, but will have to see.

I could not figure out how to overload a property with single/integer return value. I think because it's just the return type of the property that differs it may not work when overload , or I just did it wrong!

In any case, I'm going to move forward and see how incompatible it is when I get further along.

Sandy