Recent

Author Topic: Making sure a form gets focus  (Read 1397 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Making sure a form gets focus
« on: August 07, 2020, 10:36:15 am »
I know this is an FAQ, but so far Google's let me down.

I've got a program which interprets a magical event (double-click with some keys pressed) as an instruction to make a debugging form visible. The debugging form contains a memo, and the memo has a double-click handler which controls the visibility of the form's status bar.

Now this is obviously purely cosmetic, but unless the memo has already been explicitly clicked the first double-click is ignored. I presume this is a focus issue but so far I've not found how to force it, and most discussion on Google relates to how /not/ to give a form or control focus when it's made visible.

Linux AMD64 GTK2, Lazarus "Trunk".

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Making sure a form gets focus
« Reply #1 on: August 07, 2020, 07:25:26 pm »
My suspicion is that this is caused because a "form A" activity is being used to make "form B" visible, and that some "form A" event (key-release, mouse-up etc.) is bringing focus back from "form B".

I've not found a workaround, and will probably have to live with it.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

jamie

  • Hero Member
  • *****
  • Posts: 6090
Re: Making sure a form gets focus
« Reply #2 on: August 07, 2020, 11:04:10 pm »
either simulate the mouse clicks or directly call the OnDoubleClick event from FormA.

from FormA's code that shows FormB's in this desired manner call the OnDoubleClick Handler directly from FormA of formB;

FormB.SHow;
Formb.OnDOubleClick(Self);

etc

« Last Edit: August 07, 2020, 11:07:50 pm by jamie »
The only true wisdom is knowing you know nothing

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Making sure a form gets focus
« Reply #3 on: August 08, 2020, 10:28:17 am »
Bombs with an AV. I suspect that the only way to fix this would involve either a timer (on formB) or an asynchronous event which got processed some time after formA had gone back to the quiescent state.

Interestingly, it only happens when formA makes formB visible: at other times when formA has focus formB responds immediately to a doubleclick. But it is consistent.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Making sure a form gets focus
« Reply #4 on: August 08, 2020, 02:02:29 pm »
I've now tried various combinations of spoofing a doubleclick when formA makes formB visible, in formB's OnShow() handler, some while later using an asynchronous event, and 100 mSec later using a timer. In all cases, I'm stuck with the behaviour that the first doubleclick on the memo is lost.

This is really only cosmetic and being a debugging facility is most unlikely to be used by anybody except myself, so I'm not putting any more work into it.

I find that Qt works as expected, i.e. the first doubleclick isn't lost. I've not tried any other widgetset.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

jamie

  • Hero Member
  • *****
  • Posts: 6090
Re: Making sure a form gets focus
« Reply #5 on: August 08, 2020, 02:24:27 pm »
That sounds like buggy widget interface code to me..

 if the form is pre-created and all that needs to be done is just a show then there shouldn't be any troubles. However, if it's not pre-created then it may need to preform a read from resource.

 The other option which is simple btw, is to post a user message to FORMB where by when it receives the message later (msec) you can provide a handler for it which you then include your code to process the form as you wish.

Procedure MyForcedMessage(var msg:Tmessage); Message LM_USER+1;

and In the implementation section just provide the method body for that handler..

Procedure TFormB.MyForceMessage(Var Msg:Tmessage);
begin
 OnDoubleClick(Self);
End;

You may need to include the Lmessages unit.

The only true wisdom is knowing you know nothing

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Making sure a form gets focus
« Reply #6 on: August 08, 2020, 03:21:50 pm »
The form is procreated and I think something's screwed.

Creation is handled in the usual place (.lpr main unit), formA is the main form and formB starts off non-visible. I can make formB visible by double-clicking on one of formA's panels with a key combination also pressed, I can hide it using its close button.

Every time formB is made visible, its first doubleclick is ignored.

I've not investigated yet whether I can duplicate this using a minimal test project. Please would somebody advise if they think this is worth the effort.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: Making sure a form gets focus
« Reply #7 on: August 08, 2020, 08:22:33 pm »
The form is procreated and I think something's screwed.
:D :D :D
Was that "off-tone" joke intended or is it a weird typo? I mean, that's how things are usually "procreated" here on Earth, isn't it?  ;D

Sorry for the off-topic; couldn't resist :-X

Back on topic, I made a simple test (Xubuntu 18.04-amd64, attached) and couldn't reproduce the behaviour you're seeing. You'll have to post a sample project for us to try to see what's happenning.
« Last Edit: August 08, 2020, 08:44:30 pm by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

jamie

  • Hero Member
  • *****
  • Posts: 6090
Re: Making sure a form gets focus
« Reply #8 on: August 08, 2020, 09:01:32 pm »
The form is procreated and I think something's screwed.
:D :D :D
Was that "off-tone" joke intended or is it a weird typo? I mean, that's how things are usually "procreated" here on Earth, isn't it?  ;D

Sorry for the off-topic; couldn't resist :-X

Back on topic, I made a simple test (Xubuntu 18.04-amd64, attached) and couldn't reproduce the behaviour you're seeing. You'll have to post a sample project for us to try to see what's happenning.

At least we have some sense of humor around here  :D
The only true wisdom is knowing you know nothing

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Making sure a form gets focus
« Reply #9 on: August 08, 2020, 09:58:39 pm »
Sorry for the off-topic; couldn't resist :-X

Back on topic, I made a simple test (Xubuntu 18.04-amd64, attached) and couldn't reproduce the behaviour you're seeing. You'll have to post a sample project for us to try to see what's happenning.

Creative use of spieling chuckler :-)

I'll try to do a cut-down test, but it's very likely to be one particular gtk2 release.

Wish I'd tried Qt earlier, it rather validates my longstanding philosophy of having multiple target systems available.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Making sure a form gets focus
« Reply #10 on: August 09, 2020, 12:06:56 pm »
OK, what I can say is this.

* I can demonstrate the problem on Debian "Stable" (10?) and "Old stable" AMD64 GTK2.

* I don't see a problem using Qt on the above platforms.

* I don't see a problem on a much older (Debian "Lenny") x86.

* I can't duplicate it with a simple test program.

My own suspicion is that it's a weird interaction of event handlers on formA, e.g. it tracks the shift keys pressed although that in isolation doesn't appear to be the problem so there has to be something additional.

This is purely cosmetic, and at least in my case probably won't need to be explained to an ordinary user. I've lost a bit of time trying to sort it out, but I suggest that the community as a whole doesn't put any effort into it unless somebody else experiences something comparable (the converse being that if somebody else thinks he's seeing something like this, he's not chasing an imaginary ghost).

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018