TSpinEdit Min/Max behaviour

[Bart]

I have been thinking about this (only use upper or lower limit) a bit more.
This could of course be achieved with yet another property, let's call it LimitBehviour, with values slbBoth, slbUpperLimit, slbLowerLimit or similar.
The first would behave like it currently is, and therefore should be the default.

The method GetLimitedValue could then easily be adapted.
For T(Float)SpinEditEx, that would be all there is to do.

For T(Float)SpinEdit however this behaviour must be implemented in the widgetset code for all widgetsets we support. E.g. in GTK2 you must adapt the min and max values of the used widget to achieve this.

The question that I have is: is having a new property to implement such a feature really that much easier or better than simply setting either MaxValue to High(basetype) or MinValue to Low(basetype)?
In design-time probably, but @runtime certainly not.

Bart

[wp]

I think there is no benefit of a "LimitBehaviour" property. Suppose somebody wants to allow a spin range starting at 5 up to infinity. In the current version he has to specify Minvalue to be 5 and Maxvalue to be some huge value. If there were a LimitBehaviour property he'd have to enter MinValue=5 and LimitBehaviour=slbLowerLimit - two properties to be changes, no advantage. Only when the MinValue is 0 he could skip this because it is the default value.

[Bart]

I think there is no benefit of a "LimitBehaviour" property.
[snip]

Exactly.

Bart

[Muso]

The current behaviour of unlimited spinning when Min <> 0 and Max = 0 appears to be a bug. Would you report it?

Here is the bug report:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39532

What does that mean: "if one limit is given but the other one not"?

In the *.lfm file there is a MinValue but no MaxValue.

[Muso]

E.g. MinValue=100, MaxValue=200. I want it to be MinValue=-50, MaxValue=50.
Since MaxValue comes alphabetically before MinValue it will be above MinValue in the OI.
Therefore it it rather natural to first change MaxValue into 50, but now the IDE will show me an error message?

Not necessarily. Here are 2 possibilities:

Possibility A: I take wp's example code to set the Min/Max for chart axes. This is the same task, Max must be >= Min. Since my users are "just users", I cannot bother them with error messages, therefore you can simple only insert what is allowed, see attached.
In the screencast the limit should become 20 - 50.

[Muso]

Possibility B: This is how the CAD software FreeCAD handles such cases, see attached

Despite I wrote this implementation, I prefer possibility A. If A or B is just a matter of taste.

[Bart]

None of these proposals take away my objections in Reply #11.

Bart

[Muso]

None of these proposals take away my objections in Reply #11.

I get no info what reply #11 was from the forum software. However, why do you think both possibilities can't be used?

thanks and regards
Uwe

[Bart]

The current behaviour of unlimited spinning when Min <> 0 and Max = 0 appears to be a bug. Would you report it?

Here is the bug report:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39532

Again: your description is incorrect.
As I tried to explain this behaviour is not a bug, it is so by design and has been so for ages.
I will not "fix" that.

See my further comments in the bugtacker on yor proposals.

Bart

[Muso]

As I tried to explain this behaviour is not a bug, it is so by design and has been so for ages.

Please don't be upset. I described briefly why it is new and how it occurs. And I came to this via real life:
- I wrote a laboratory measurement software for my colleagues.
- 2 weeks ago I updated my Laz build system completely to Laz 2.2 and recompiled everything
- now I got the feedback that my program crashes all the time
- it took me a while to figure out why:
 they enter values like "0.5" by typing ".5". But just "." is interpreted as zero and triggers a division by zero. As I set a MinValue of "0.1" this did not happen with Laz 2.0

So why should others have the same problem as I had? The issue is real for the users.

[wp]

I do agree with Muso here that Max < Min is allowed and is used to indicate a request for unlimited spinning is rather unusual and confusing. In fact, I did not even know of this "feature" and always left MaxValue and MinValue at their default when I needed unlimited spinning.

Checked with Delphi 7 and XE10.3:
* MaxValue=-10, Minvalue=10 --> ok, there is no error message, but also, there is no unlimited spinning: clicking the spin buttons makes the edit jump between -10 and 10 without the intermediate values.
* MaxValue = 0, MinValue = 0 --> unlimited spinning

[Bart]

Please don't be upset.

I'm not upset.

I merely reacted to the fact that I pointed out to you that:

• Your initial, observations were wrong, and I told you so. Yet you repeat them.
• I pointed out that the behaviour when MaxValue<MinValue is by design, and that this is not going to change.
• I explained that there were good reasons not to enforce MaxValue>=MinValue.
• I referred you to the relevant release notes.

From that I would have gathered that it was clear that:

• Yes, new behaviour is not backwards compatible.
• The new behaviour is by design.

And yet you filed a bugreport...

Now it's my turn to ask you some questions:

• Did you read the release notes before you upgraded?
• Did you do regression test of your software before you enrolled the version built with Laz 2.2  into production?

Bart

[wp]

they enter values like "0.5" by typing ".5". But just "." is interpreted as zero and triggers a division by zero. As I set a MinValue of "0.1" this did not happen with Laz 2.0

Then the issue is in your application. You must protect your code against a division by zero. You are cheating when you push this task to the FloatSpinEdit. Either put your calculation in a try-except block to catch the divide-by-zero exception, or, better, query the FloatSpinEdit value before entering the calculation, skip the calculation and show an error message if needed.

[Bart]

Checked with Delphi 7 and XE10.3:
* MaxValue=-10, Minvalue=10 --> ok, there is no error message, but also, there is no unlimited spinning: clicking the spin buttons makes the edit jump between -10 and 10 without the intermediate values.

I refer you to the comments in GetLimitedValue.
The Delphi behaviour with MaxValue<MinValue is idiotic, and it is exactly this reason why I decided not to implement this.
As I said before: there is no reason to duplicate the bugs of Delphi.
I cannot imagine that you would also want to implement this like D7 (and IIRC also D3) does?

And yes, I do agree that it feels a bit counter-intuitive that setting MaxValue<MinValue also "unlimits" the control.

Nevertheless: having MaxValue<MinValue is not illegal for TSpinEdit, not in Lazarus and also not in Delphi.
Therefore the IDE should not disallow that IMHO.

But I am not going to start a war about that part.
If more devels find this should be implemented, I will go ahead and do so.

Of course, one can expect yet another bugreport about this behaviour when this will be the case.
And then requests to make it also kike this when setting MaxValue<MinValue in code.
And then we have bugs loading LFM's and all this will start over and over again.

Bottom line is that bugs needed to be fixed.
The old behaviour was wrong and the new behaviour is not the old behaviour, so not backwards compatible.
Unfortunately, sometimes this cannot be avoided and IMO this is such a case.

Bart

[Bart]

they enter values like "0.5" by typing ".5". But just "." is interpreted as zero and triggers a division by zero. As I set a MinValue of "0.1" this did not happen with Laz 2.0

Then the issue is in your application. You must protect your code against a division by zero. You are cheating when you push this task to the FloatSpinEdit. Either put your calculation in a try-except block to catch the divide-by-zero exception, or, better, query the FloatSpinEdit value before entering the calculation, skip the calculation and show an error message if needed.

I guess your calculation is triggered by the OnChange of the control?
If so, that is a bad idea IMO.

Bart