TSpinEdit Min/Max behaviour lazarus / 31-LCL ---------------------------------------------------------------------- Muso · 2022-01-03 11:31 There is a major regression that the min/max values of edit fields is no longer respected: - run the attached minimal program with Laz 2.0.12 result: everything is fine. When you enter a zero, it is immediately transformed to the set minimum "0.1" for the edit - now run the same program with Laz 2.2.0git (I have rev lazarus_2_2_0-6-g4734343934, FPC 3.2.3 x86_64-win64-win32/win64 ) result: you get a division by zero because the set minimum is not respected. I assume a regression because in the release notes I cannot find that the different behavior was intended. Can anyone reproduce this? ---------------------------------------------------------------------- Muso · 2022-01-03 12:00 Quote from: Muso on January 03, 2022, 12:31:18 pmThere is a major regression that the min/max values of edit fields is no longer respected: I see now that the bug only occurs if a minimal value is set but no maximal value. If a maximal value is mandatory when a minimal value is set, this must appear somewhere in the Laz 2.2 release notes. While we are at it, the IDE should be changed by automatically setting a maximal value of maybe 1.0 above the minimal value. As it is, I can e.g. set "11" as minimal value and "2" as maximum. The IDE should not allow this. It is not that users are stupid, but typos occur, in my example I wanted to set "1" as minimum but accidentally hit the 1 twice. It is therefore very valuable in getting feedback about my mistake. Should/can I report this in the bug tracker? ---------------------------------------------------------------------- Martin_fr · 2022-01-03 12:03 I don't think it should be mandatory. I suggest to report it (if no one else has done yet). ---------------------------------------------------------------------- wp · 2022-01-03 12:44 Quote from: Muso on January 03, 2022, 12:31:18 pmThere is a major regression that the min/max values of edit fields is no longer respected [...] I assume a regression because in the release notes I cannot find that the different behavior was intended. A TEdit control does not have a minimum/maximum value. Your are talking of T(Float)SpinEdit(Ex), aren't you? There was a change some time ago in which the default of the maximum value has been changed to become Delphi compatible; the code incompatibility has been documented at https://wiki.freepascal.org/Laz arus_2.2.0_release_notes#T.28Float.29SpinEdit.28Ex.29_default_value_fo r_MaxValue_changed. ---------------------------------------------------------------------- Muso · 2022-01-03 13:01 Quote from: wp on January 03, 2022, 01:44:33 pmThere was a change some time ago in which the default of the maximum value has been changed to become Delphi compatible; the code incompatibility has been documented at https://wiki.freepascal.org/Lazarus_2.2.0_release_notes#T.28Float.2 9SpinEdit.28Ex.29_default_value_for_MaxValue_changed. Stupid me that I did not find this. However, there it is written QuoteOld behaviour: the default value of MaxValue was 100 So the 100 was in effect. Why is this then not kept? I mean It is a nightmare to look through all my programs now to check if my 100 as max value now suddenly became a 0. Can the the IDE please don't automatically change set values? It is OK that the new default is set for new elements but existing elements should not be changed automatically. I also don't understand why the maximum can now be smaller than the minimum. This is very error-prone because as I wrote accidental inputs can happen quickly and you get no feedback from the IDE that because of a typo you SpinEdit is not limited at all. So having max < min leads to the case that the limits are ignored so this should not be allowed because the user's will is obviously to have limits, otherwise he would not have entered them. ---------------------------------------------------------------------- wp · 2022-01-03 14:56 Quote from: Muso on January 03, 2022, 02:01:54 pmHowever, there it is written QuoteOld behaviour: the default value of MaxValue was 100 So the 100 was in effect. Why is this then not kept? I mean It is a nightmare to look through all my programs now to check if my 100 as max value now suddenly became a 0. Can the the IDE please don't automatically change set values? It is OK that the new default is set for new elements but existing elements should not be changed automatically. This is not possible. When a property is declared with a default value and the property value is equal to the default value then the property is not written to the lfm file. So, when you open your project in the IDE and the streamer does not find this property in the lfm then the value of the property with which it was created is kept. In Laz 2.2+, the MaxValue after creation is 0, in older versions it was 100. Quote from: Muso on January 03, 2022, 02:01:54 pmIt is a nightmare to look through all my programs now to check if my 100 as max value now suddenly became a 0.In all my programs the max very rarely is 100, and thus in the majority of cases it is different from the default of the old Laz versions and thus is written to the lfm. But I agree it is quite some effort to find all the changed cases in a large code base. Quote from: Muso on January 03, 2022, 02:01:54 pmI also don't understand why the maximum can not be smaller than the minimum. The current behaviour of unlimited spinning when Min <> 0 and Max = 0 appears to be a bug. Would you report it? Not sure about the condition of Max < Min. It could also be interpreted to be intentional (although it does not appear to be very logical): The question is how the effect of a one-sided limit can be achieved, e.g. limit the MinValue, but define none for the MaxValue. Three possibilities come to my mind - Make the MaxValue larger than the MinValue - I think this is confusing: Is the upper limit unbound? Or is the lower limit unbound? - Add a new property FixedLimits = set of (fixedMin, fixedMax). - Enter a "huge" value for MaxValue (e.g. MaxInt for the SpinEdit). Very simple, and looks fine. I am not the author of these components, but I'd favour the third option. I also tend to raise an exception when MaxValue < MinValue. But when? During streaming? This would lead to one of these nasty streaming errors which make it impossible to load a form... In the Object Inspector? But then the error will slip through at runtime. When at runtime? Could not find a good place after a quick search... [/quote] ---------------------------------------------------------------------- Muso · 2022-01-03 16:24 Quote from: wp on January 03, 2022, 03:56:06 pmThis is not possible. When a property is declared with a default value and the property value is equal to the default value then the property is not written to the lfm file. Thanks, I see now. Quote from: Muso on January 03, 2022, 02:01:54 pmIt is a nightmare to look through all my programs now to check if my 100 as max value now suddenly became a 0. In my case it affected all spinEdits for percentages. So I fixed this using a text editor (jEdit) to fix all *.lfm files at once. Quote from: wp on January 03, 2022, 03:56:06 pmThe current behaviour of unlimited spinning when Min <> 0 and Max = 0 appears to be a bug. Would you report it? I will do so later today. Quote from: wp on January 03, 2022, 03:56:06 pmNot sure about the condition of Max < Min. It could also be interpreted to be intentional (although it does not appear to be very logical): The question is how the effect of a one-sided limit can be achieved, e.g. limit the MinValue, but define none for the MaxValue. This is my proposal: - if one limit is given but the other one not, the max value will internally be used. So if it is a TSpinEdit, this would be +MaxInt, in case of a TFloatSpinEdit, the it is +MaxDouble So I propose almost the same as you, with the difference that the user doesn't have to enter the Max value manually. Quote from: wp on January 03, 2022, 03:56:06 pmI also tend to raise an exception when MaxValue < MinValue. But when? Directly when entering the value in the IDE a dialog should pop up. I think of the same dialog that appears when you enter for a TSpinEdit a double as MinValue. Then the IDE also immediately tells you that you made a mistake. ---------------------------------------------------------------------- Bart · 2022-01-03 16:53 Quote from: Muso on January 03, 2022, 05:24:03 pmQuote from: wp on January 03, 2022, 03:56:06 pmThe current behaviour of unlimited spinning when Min <> 0 and Max = 0 appears to be a bug. Would you report it? I will do so later today. First of all, your observation is wrong. If MinValue=-100 and MaxValue=0, the control is limited in it's spinning. It is unlimited however if MinValue is NOT less than MaxValue. From the sources: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function TCustomFloatSpinEdit.GetLimitedValue(const AValue: Double): Double;begin  Result := AValue;  //Delphi does not constrain when MinValue = MaxValue, and does if MaxValue < MinValue,  //but the latter makes absolutely no sense at all.  if FMaxValue > FMinValue then  begin    if Result < FMinValue then Result := FMinValue;    if Result > FMaxValue then Result := FMaxValue;  end;end; Notice the comments in the code. How do you think the behaviour should be if MinValue=10 and MaxValue=1? Should only Values <=1 and Values>=10 be accepted? Should MinValue and MaxValue be swapped (with or without a user notification)? The names of these two properties to me at least suggest that a MaxValue should be greater than or equal to MinValue. B.t.w. This has been implemented so for a long, long time. Bart ---------------------------------------------------------------------- Muso · 2022-01-03 17:29 Quote from: Bart on January 03, 2022, 05:53:56 pmFirst of all, your observation is wrong. If MinValue=-100 and MaxValue=0, the control is limited in it's spinning. It is unlimited however if MinValue is NOT less than MaxValue. Yes and this is what I wrote. The regression bug is therefore a combination of these two things: - I have SpinEdits for percentages, therefore I only set a MinValue, no MaxValue - now the unset MaxValue is interpreted as 0, so in fact I suddendly have MinValue > 0, MaxValue = 0 and in this state the spin is unlimited Finding this, and fixing cost me a lot of time because it is very confusing. The solution would be as I or wp proposed. Quote from: Bart on January 03, 2022, 05:53:56 pmHow do you think the behaviour should be if MinValue=10 and MaxValue=1? - the IDE should not allow this setting - the same way as it for example does not allow to set a double as MinValue for the integer- based TSpinEdit. - when you set a MinValue > MaxValue at runtime, Lazarus should output at least a warning when compiling. ---------------------------------------------------------------------- Bart · 2022-01-03 21:45 In the past setting MaxValue < MinValue was prohibited, but lead to unwanted side effects (bugs) upon loading the component from LFM, so this was abandoned. See T(Float)SpinEditEx MaxValue is no longer enforced to be >= MinValue About default MaxValue now being 0 instead of 100: this was also reported in the same release notes. Bart ---------------------------------------------------------------------- Bart · 2022-01-03 21:52 Quote from: Muso on January 03, 2022, 05:24:03 pmThis is my proposal: - if one limit is given but the other one not, the max value will internally be used. So if it is a TSpinEdit, this would be +MaxInt, in case of a TFloatSpinEdit, the it is +MaxDouble What does that mean: "if one limit is given but the other one not"? MinValue and MaxValue both are give at any time. Bart ---------------------------------------------------------------------- Bart · 2022-01-03 21:59 Quote from: Muso on January 03, 2022, 05:24:03 pmDirectly when entering the value in the IDE a dialog should pop up. I think of the same dialog that appears when you enter for a TSpinEdit a double as MinValue. Then the IDE also immediately tells you that you made a mistake. So now you are in fact forcing the user to change the values of MinValue and MaxValue in a particular order, depending on what the situation before change was, and what the end result should be. 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? Bart ---------------------------------------------------------------------- wp · 2022-01-03 22:10 Quote from: Bart on January 03, 2022, 10:52:33 pmWhat does that mean: "if one limit is given but the other one not"? I think he means, for example, to set only a lower limit, so that the values can only increase above this limit up to "infinity", but not below it. Likewise with an upper limit. If we had specified the TSpinEdit default values for MaxValue to be MaxInt and that for Minvalue to be -(MaxValue+1) the user would have to change only a single value to achieve this behaviour. If he'd set MinValue=5 and keep MaxValue at this default (MaxInt) he would be able to enter any value >= 5, but nothing smaller. Now he must set both Maxvalue and MinValue for this purpose. No big problem, I think... ---------------------------------------------------------------------- wp · 2022-01-03 22:14 Quote from: Bart on January 03, 2022, 10:59:20 pmSince 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? Very good point. I hate software which thinks for me while I am typing. ---------------------------------------------------------------------- Bart · 2022-01-03 23:29 Quote from: wp on January 03, 2022, 11:10:47 pmQuote from: Bart on January 03, 2022, 10:52:33 pmWhat does that mean: "if one limit is given but the other one not"? ... If we had specified the TSpinEdit default values for MaxValue to be MaxInt and that for Minvalue to be -(MaxValue+1) the user would have to change only a single value to achieve this behaviour. Aha, I see. If we would have had total freedom to desing from the ground up it might have been this way. Unfortunately we have to take the behaviour of Delphi into account (that does not mean we also have to implement their bugs as well though). Either way, none of this can be resolved without breaking backwards compatibility. (As we clearly already did because we had to fix bugs and conform to defualt valuus for MinValue/MaxValue that Delphi uses.) Bart ---------------------------------------------------------------------- Bart · 2022-01-04 10:04 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 · 2022-01-04 13:52 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 · 2022-01-04 14:03 Quote from: wp on January 04, 2022, 02:52:40 pmI think there is no benefit of a "LimitBehaviour" property. [snip] Exactly. Bart ---------------------------------------------------------------------- Muso · 2022-01-04 16:00 Quote from: wp on January 03, 2022, 03:56:06 pmThe 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 Quote from: Bart on January 03, 2022, 10:52:33 pmWhat 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 · 2022-01-04 16:13 Quote from: Bart on January 03, 2022, 10:59:20 pmE.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 · 2022-01-04 16:17 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 · 2022-01-04 16:35 None of these proposals take away my objections in Reply #11. Bart ---------------------------------------------------------------------- Muso · 2022-01-04 16:38 Quote from: Bart on January 04, 2022, 05:35:42 pmNone 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 · 2022-01-04 16:38 Quote from: Muso on January 04, 2022, 05:00:10 pmQuote from: wp on January 03, 2022, 03:56:06 pmThe 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 · 2022-01-04 16:44 Quote from: Bart on January 04, 2022, 05:38:39 pmAs 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 · 2022-01-04 17:11 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 · 2022-01-04 17:20 Quote from: Muso on January 04, 2022, 05:44:25 pmPlease 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.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 · 2022-01-04 17:24 Quote from: Muso on January 04, 2022, 05:44:25 pm 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 · 2022-01-04 17:33 Quote from: wp on January 04, 2022, 06:11:40 pmChecked 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 * MaxValue = 0, MinValue = 0 --> unlimited spinning Makes sense because you need a state in which the edit is unlimited. > * 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. Understandable as well because what else would you do if max < min is allowed? In my opinion the good point with this implementation is that that is makes the right assumption: the user explicitly set a limit, so the user want a limit. He might have set max < min just because of a typo or so (e.g. setting min to "11" instead of the intended "1"). When testing the program he quickly sees the issue. So please don't beat me that I find the implementation reasonable. I should better say since max < min is not forbidden, I don't have a better idea for an implementation. ---------------------------------------------------------------------- Bart · 2022-01-04 18:07 Quote from: Muso on January 04, 2022, 06:47:53 pm OK. This is new to me. I program also with Qt and there all the limit handling is done by Qt directly. So before the "OnChanged" signal is evaluated, the limit checker does its work. So entering a value out of the limits does not trigger an OnChange event. How is this with LCL? AFAIK the OnChange is invoked whenever the user makes a change in the control, so when the text in the control ie e.g. '1.0'  and the user types a '0' before the '1', then an OnChange should be triggered. (If that is not the case in QT, then this looks like a bug to me.) On Windows it is possible to paste arbitrary text into the control, or completely clear the control. When you query Value, this will hold a value of course (Value is not of a nullable type), but that may at this point in time not be what you expect. E.g. the control currently reads '1.1', I manually (by typing) change that to '21.0', then place the caret behind the '0' and press Backspace until the control is empty. When the control is empty, Value will be 2.0. Is this what you expected? Also: inserting zero's before the first digit repeatedly (most likely by accident) will keep on triggering OnChanges, but the Value never changes. This can be avoided by setting EditorEnabled to False (but I do not know if this property exists in Laz 2.2). Currently I think however that it is not possible to distinguish between an OnChange fired because the spinners were clicked (Value is always correct) or by editing the text (Value may not be what you expect). In a perfect world the control should maybe have a "OnValueChanged" event? Bart ---------------------------------------------------------------------- wp · 2022-01-04 18:20 Quote from: Muso on January 04, 2022, 06:47:53 pmI program also with Qt and there all the limit handling is done by Qt directly. So before the "OnChanged" signal is evaluated, the limit checker does its work. So entering a value out of the limits does not trigger an OnChange event. How is this with LCL? In my case it is a motor control. With less than 0.1 % of it max. power, it doesn not spin, with negative values, it would spin in the other direction. Therefore I simply set the MinValue to "0.1". I wrote this software about 2 years ago and up to now it worked well - when you try to enter a zero or minus sign, you cannot do this and the onChanged event is not triggered - like it is with Qt. So did I made a big mistake for a long time? Suppose you have a procedure SpinMotor(Power: Double) which you call from the OnChange event of the SpinButton. You know that when SpinButton.Value is zero the procedure will crash. You prevent this you set the SpinButton.MinValue to 0.1 -- fine. But some time in the future you have a great idea and call SpinMotor from another place in your code, and the Power argument is provided from somewhere else which is not protected to become zero. Now you have that old problem again... It is so easy to fix the issue without any requirements on TSpinEdit: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i procedure SpinMotor(Power: Double);begin  if Power < 0.1 then begin    ShowMessage('Power too small to spin the motor.');    exit;  end;  // Now do the calculation which can NEVER get a Power = 0  // ...end; ---------------------------------------------------------------------- Bart · 2022-01-04 18:26 Quote from: Muso on January 04, 2022, 07:00:51 pm > * 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. Understandable as well because what else would you do if max < min is allowed? Ok: MinValue means: Minimal Value. MaxValue means: Maximum Value. MinValue = 10 MaxValue = -10 How can any number be <= -10 and at the same time >= 10? It cannot be. The behaviour of the control in this case is "undefined", as in: it is never described in the documentation (of Delphi) how it should behave. The behaviour in Delphi is most likely a side effect of how it was implemented. (Naïve approach: if ValueMaxValue then Value:=MaxValue. Mind you I never looked at the source code of Delphi's TSpinEdit.) Most likely they never even considered a user causing this. For the same reason ("undefined") our implementation is valid as well. IMO it is a bit less moronic then Delphi's implementation. Most users (like you) will never have MinValue>MaxValue and will never encouter our implementation, nor Delphi's one. (When I implemented it this way, I did blackbox testing agains D3 and tried to think of weird situations and then stubled upon this.) In both cases (Delphi as well as Lazarus) they will find out the control behaves not exactly as they intended. There is no "proper" way to handle this situation. Raising an exception? Now the programmer always has to first examine the value of both MinValue and MaxValue if he wants to change both. Simply disallow it? Same problem. If primitive types were nullable, Value could return Null. That would at least make some sense of it all. But since that is not the case, we must return an actual Double or Integer. Bart ---------------------------------------------------------------------- Bart · 2022-01-04 18:30 PS. While "undefined" in practice means: "anything goes", since the behaviour when MaxValue= 10? It cannot be. Exactly and that is why I would not allow this. But as you stated it is **not** forbidden. Thus the UI must somehow allow this. Therefore I wrote, under these circumstances I don't have a better idea than what the Delphi guys implemented. You know my opinion that I would change the IDE not to allow max < min. We debated the pros and cons and I think you can make a decision on what the IDE should allow. If max < min should be allowed by the IDE, then Delphi's implementation makes sense to me. However since I am an LCL newbie, you and wp should debate this and I should be quiet now   . ---------------------------------------------------------------------- Bart · 2022-01-04 21:06 Quote from: Muso on January 04, 2022, 07:39:31 pmHowever since I am an LCL newbie, you and wp should debate this and I should be quiet now   . No, you should not be quite, at least not because you're a newbie and I'm not. I welcome your input, even though we disagree. This discussion gives us insight in what a common user expects and, just because of that, it's worthwhile. Bart ---------------------------------------------------------------------- jamie · 2022-01-04 22:36 Been following this thread a bit.. Using Trunk on windows 10. The FloatSpinEdit allows me to enter multiple ".", should that be happening ? Also,  Implementing the OnEditingDone I noticed that when using the keyboard any value I type in out of range will be corrected when hitting the enter key to fit the range however, it does not properly update the EDIT window to show the in range value that it just got changed to , the out of range value which is incorrect is still showing.  I did notice however if I move to another control using the Mouse and maybe the tab key it then updates. Just something I noticed and yes I am sure it can be corrected in user code too but it just seems strange to me. ---------------------------------------------------------------------- Bart · 2022-01-04 22:46 Quote from: jamie on January 04, 2022, 11:36:18 pmThe FloatSpinEdit allows me to enter multiple ".", should that be happening ? The code that does this actually only blocks keys that can never be allowed, e.g. 'a'. The lagorithm to detect wether a dot is allowed might look straigh forward (only allow if it is not already there) , but then again, if I want to change 12.3 into 1.23 and I do so by first typing the '.' after the '1' and then proceed to delet the '.' after the '2', I cannot do so. So, I considered the simple approach and rejected it. (Notice that (on Windows at least) you can paste any amount of garbage into the control, so being too tight in rejecting key-input makes little sense.) Quote from: jamie on January 04, 2022, 11:36:18 pmImplementing the OnEditingDone I noticed that when using the keyboard any value I type in out of range will be corrected when hitting the enter key to fit the range however, it does not properly update the EDIT window to show the in range value that it just got changed to , the out of range value which is incorrect is still showing.  I did notice however if I move to another control using the Mouse and maybe the tab key it then updates. That doesn't sound quit allright to me... I'll try to look into that. However: this is off-topic to this thread. Bart ---------------------------------------------------------------------- Bart · 2022-01-05 11:38 Quote from: Bart on January 04, 2022, 11:46:49 pmThat doesn't sound quit allright to me... I'll try to look into that. @Jamie: can you please test with #603fb729459c5ca1db91e5cc69397f3c02b19067? Bart ---------------------------------------------------------------------- jamie · 2022-01-05 21:50 Quote from: Bart on January 05, 2022, 12:38:37 pmQuote from: Bart on January 04, 2022, 11:46:49 pmThat doesn't sound quit allright to me... I'll try to look into that. @Jamie: can you please test with #603fb729459c5ca1db91e5cc69397f3c02b19067? Bart Yes, it seems to work,.. I can just hit the Enter key and it will correct itself in the display. I also checked with the others and they seem to be working, too. Thank you.