I have only tested this on Windows XP with 0.9.24 (fpc 2.2.0), so I
don't know if it affects the other widget sets (gtk1/2, qt, etc) or
not, or if it's even really a bug and not just standard (but bizarre)
behavior. Here's the scenario. When manually editing a tspinedit
control (i.e., by clicking in the edit box and typing in a value,
instead of simply clicking on the up/down buttons or using the up/down
arrow keys to change the value), it is possible to enter a value
outside the min/max range of the control. BUT, and this is the weird
part, the TSpinEdit.Value field is still constrained by the min/max
settings and now holds the correct min or max value, however the edit
box itself is not updated properly to reflect this and still shows the
invalid value.
This is probably a bug, and if so I will report it. But read on to see
the exact description of the problem and tell me if it's really a bug
or if it's supposed to behave this way. I hope it's a bug, because in
my current project I've got several TSpinEdit controls that I need the
user to be able to manually edit in addition to using the "spin"
buttons, but I still need to enforce the constraints and have the user
see that the constraint is enforced.
To demonstrate what I'm talking about, create a new project with an
empty form and place a single TSpinEdit control on it, with
SpinEdit1Change as the callback for the OnChange event. The procedure
should only contain one statement:
ShowMessage('SpinEdit1.Value = ' + IntToStr(SpinEdit1.Value));
This will pop up a message box showing the value of the control
whenever the OnChange event is triggered.
Now, when the program is compiled and run, click in the edit box,
place the cursor in front of the "0" and type a "1" (to manually input
a value of 10). The message box will pop up saying "SpinEdit1.Value =
10". Now click in the edit box again, place the cursor at the front of
the "10" and type a "-" (a negative or minus sign). The message box
will respond with "SpinEdit1.Value = 0", since the bounds are by
default 0 to 100. This means that the constraints kicked in and
prevented the control from having a value of -10 and instead limited
it to 0. However, the edit box will still display "-10". You can move
focus away from the form and then return to it, minimize and restore
it, and if there are more controls on the form you can move focus to
them and away from the spin edit, but the control will still show
"-10". So how can you tell it's Value field is really "0"? Click on
the up button (or press the up arrow). The message box will now say
"SpinEdit1.Value = 1", and the control will now correctly display "1".
The complete unit1.pas file to demonstrate the above example is:
----begin unit1.pas----
unit Unit1;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, LResources, Forms, Spin;
type
{ TForm1 }
TForm1 = class(TForm)
SpinEdit1: TSpinEdit;
procedure SpinEdit1Change(Sender: TObject);
private
{ private declarations }
public
{ public declarations }
end;
var
Form1: TForm1;
implementation
{ TForm1 }
procedure TForm1.SpinEdit1Change(Sender: TObject);
begin
ShowMessage('SpinEdit1.Value = ' + IntToStr(SpinEdit1.Value));
end;
initialization
{$I unit1.lrs}
end.
----end unit1.pas----
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
