TAB key, TDBEdit focus and Exceptions
lazarus / 31-LCL

----------------------------------------------------------------------
Walmir · 2014-08-28 13:39

Hi,
I have the following code  in an OnValidate event of a TField:
Code: [Select]procedure TdmData.ValidaCod(Sender: TField);
begin
  if Sender.Value <> '' then
    if not VerifCod(Sender.Value) then
      raise Exception.Create('Invalid code.');
end;
If the user puts an invalid TStringField in the TDBEdit and hits TAB,
the excecption is  raised; hitting "Ok" in the respective dialog
causes the focus to be placed in the next TDBEdit.
But the focus shouldn't be placed in the TDBEdit where the invalid
field is?

----------------------------------------------------------------------
Bart · 2014-08-28 16:33

Why should it?
You raise the eception yourself, how is the widgetset supposed to know
that you want the focus back to the control you just left?

Set the focus back yourself (before raising the exception, or in a
try..finally construct after the exception).

Bart

----------------------------------------------------------------------
Walmir · 2014-08-28 18:16

Quote from: Bart on August 28, 2014, 06:33:18 pmWhy should it?
Mainly because it is a desirable RAD characteristic.
Maybe because it is the logic thing to do in an OnValidate event that
fires an exception.
Also maybe just because Delphi does it...

Quote from: Bart on August 28, 2014, 06:33:18 pmYou raise the eception
yourself, how is the widgetset supposed to know that you want the
focus back to the control you just left?
I sincerely think anyone wants the focus back to the control where the
error ocurred and the widgetset is supposed to know it.
Again, Delphi does it and for about 20 years I took this behavior for
granted.
Excuse me but I noted a hint of agressivity in your answer. My
question arosed simply because I stumbled - again - in a Lazarus
behavior that is different from what I was used in Delphi.
So, I was used to expect the focus back to the control where the error
occurred and cannot be blamed by wanting it in Lazarus...

----------------------------------------------------------------------
taazz · 2014-08-28 18:31

I'm on walmir on this the event is onvalidate not onexit or
onFocuslost so an exception on tha event should render all the other
code invalid ee changing controls should not happen at all.

----------------------------------------------------------------------
howardpc · 2014-08-28 18:37

Raising an exception passes control away from the routine that raised
the exception into the RTL.
You could argue that raising exceptions for (expected, inadvertent
etc.) user data-entry errors is not appropriate anyway.
I would suggest something with a more user friendly dialog which did
not involve exceptions at all such as

Code: [Select]uses ..., Dialogs;

procedure TdmData.ValidaCod(Sender: TField);
var
  sf: TStringField;
begin
  if (Sender is TStringField) then begin
    sf:=TStringField(Sender);
    if not Verifcod(sf.Value) then begin
      ShowMessageFmt('"%s" is not valid data here',[sf.Value]);
      sf.FocusControl;
    end;
  end;
end;

----------------------------------------------------------------------
taazz · 2014-08-28 18:44

Quote from: howardpc on August 28, 2014, 08:37:27 pmRaising an
exception passes control away from the routine that raised the
exception into the RTL.
You could argue that raising exceptions for (expected, inadvertent
etc.) user data-entry errors is not appropriate anyway.
I would suggest something with a more user friendly dialog which did
not involve exceptions at all such as

Yeah that would be my choice too if I could somehow stop everything
else from executing if the validation failed. The idea is simple
validation failed then stop processing. Your solution adds more
processing to emulate a no processing state, that is backwards.

----------------------------------------------------------------------
Bart · 2014-08-29 13:02

If the behaviour differs from that from Delphi, then please file a
bugreport.
Be sure to attach a campilable sample application (sources only).

Bart

----------------------------------------------------------------------
rvk · 2014-08-29 13:30

There already is a bug entry about this:
http://bugs.freepascal.org/view.php?id=17510
It's status is fixed but i think it's only partially fixed.

The part about the focus (and stopping all other activity with the
field) apparently is not fixed:
Quote... it seems like still it merely passes on the Exception raised
in the Onvalidate code if the data isn't valid. For the OnValidate to
work as designed in Delphi, it must cancel pending events (except
Close form or close application), and keep the focus and editing on
the DB Aware component attached to the field.
Here is the forum-topic:
http://forum.lazarus.freepascal.org/index.php?topic=10628.0
and
http://forum.lazarus.freepascal.org/index.php/topic,10941.msg54607.htm
l#msg54607

----------------------------------------------------------------------
BigChimp · 2014-09-25 06:58

I know this has been a while but looking at that bug it indeed seems
like the focus issue has not been addressed.

Nothing wrong with opening a new bug report and refering to the old
one saying part of it wasn't solved...