Recent

Author Topic: TEdit.SetFocus Behaviour  (Read 12039 times)

alanphys

  • Jr. Member
  • **
  • Posts: 56
TEdit.SetFocus Behaviour
« on: November 11, 2005, 10:11:54 am »
In reply to "simple question"

Quote from: "matthijs"
Quote from: "alanphys"
I found the above discussion very informative, but it has raised an ongoing problem again that I have with Lazarus running on linux.

This code would not work. Once EditBox1 or EditBox2 has focus you cannot remove the focus from this editbox.


You are quite right, the code shouldn't work. If you enter one of the edit boxes it should lock you in it. However, running under linux the Edit1.SetFocus has absolutely no effect. Pressing Tab takes you to Edit2, or you can click on the Buttons. When the buttons are clicked the SetFocus does work. You can set the focus of the Edit boxes by pressing Button1 or Button2.

Under Windows the behaviour is even more bizarre. Entering one of the edit boxes locks you into a loop which runs for a few minutes after which control is transferred to wherever you Tab or click.

Is this a bug? My guess is the messages are not being processed correctly.

Cheers
Alanphys
Alanphys
Fedora 34 + KDE/QT5, Tinycore 8, Windows XP-10
https://github.com/alanphys

matthijs

  • Hero Member
  • *****
  • Posts: 537
TEdit.SetFocus Behaviour
« Reply #1 on: November 11, 2005, 03:01:06 pm »
It might be a bug, but then a bug in the OS. :) In a Dutch pascal usergroup forum, there is also a question on using the OnExit event of a control. It seems if you switch focus to another form or something similar in the OnExit event windows seems to loose track of where the focus is.
So if you do
Code: [Select]

procedure TForm1.Edit1Exit(Sender: TObject);
begin
  Form2 := TForm2.Create( nil );
  try
    Form2.ShowModal;
  finally
    Form2.Free;
  end;
end;

you get some strange results. Sometimes you need to click in the next control to get it to work again, although you see the cursos in it.
So what I usually advise to do is this:
When you do some checking on the contents of an edit in the on exit event do not show to a diffirent form when the contents is OK. If the contents is not OK and you want to show another form or a message put the focus back to the control you left. So using the code above, do it like this:
Code: [Select]

procedure TForm1.Edit1Exit(Sender: TObject);
begin
  if not IsOK(TEdit(Sender).Text) then begin
    Form2 := TForm2.Create( nil );
    try
      Form2.ShowModal;
    finally
      Form2.Free;
    end;
    TEdit(Sender).SetFocus;
  end;
end;
What's in a sig? Would my posting look less if it didnot have a sig? (Free after William S.) :)

:( Why cannot I upload my own Avatar? :(

alanphys

  • Jr. Member
  • **
  • Posts: 56
TEdit.SetFocus Behaviour
« Reply #2 on: November 14, 2005, 12:44:21 pm »
Nope, it works on Windows but not on Linux. As far as I can determine as soon as the Tab key is pressed the OnExit event is triggered. OnExit correctly checks the input and sets the focus, however when control is returned, the Dispatcher then sends a KillFocus message and transfers focus to the next control in the Tab order. Perhaps one of the guru's can help me out here, I am way out of my depth!

Cheers
Alanphys
Alanphys
Fedora 34 + KDE/QT5, Tinycore 8, Windows XP-10
https://github.com/alanphys

alanphys

  • Jr. Member
  • **
  • Posts: 56
TEdit.SetFocus Behaviour
« Reply #3 on: November 14, 2005, 01:24:27 pm »
Have just recompiled my app using gtk2. Joy! Everything works like it should. SetFocus returns control to the editbox. Also an annoying problem with the menus and shortcut keys has been fixed. Well done the gtk2 team.

Goodbye gtk, hello gtk2
Alanphys
Alanphys
Fedora 34 + KDE/QT5, Tinycore 8, Windows XP-10
https://github.com/alanphys

alanphys

  • Jr. Member
  • **
  • Posts: 56
Re: TEdit.SetFocus Behaviour
« Reply #4 on: February 04, 2011, 02:37:36 pm »
I know this is an old thread, but I have finally found a workaround for this problem. The solution is to include Application.ProcessMessages after Edit.SetFocus, i.e.

{Check input}
Edit1.SetFocus;
Application.ProcessMessages;

The reason I revisited this thread is that I tried to compile my apps in qt instead of gtk2 and experienced the same behaviour as gtk, and the reason I was compiling to qt was because gtk2 seems to have picked up a bug with the tab order.

I must say, it has been a long time since I have visited qt and it is really looking good.

Cheers
Alanphys
Alanphys
Fedora 34 + KDE/QT5, Tinycore 8, Windows XP-10
https://github.com/alanphys

 

TinyPortal © 2005-2018