View Issue Details

IDProjectCategoryView StatusLast Update
0017253LazarusWidgetsetpublic2019-04-22 19:33
ReporterMartin FriebeAssigned ToMartin Friebe 
PrioritynormalSeverityminorReproducibilitysometimes
Status closedResolutionunable to reproduce 
Product Version0.9.29 (SVN)Product Build 
Target VersionFixed in Version 
Summary0017253: GTK2 focus is report wrong
DescriptionThis bug has been observed in the IDE. see bug 0017207 for the exact observations.

- Debian squeeze 2.6.32-5 / libgtk2 2.20.1-1
- switching focus by tab between: non lazarus windown / main-ide-bar-win / Source-editor
- IDE does *not* use single-task-bar-button
- It is possible (but not confirmed to be the same issue) that it also happens on Ubuntu 10.04 / GTK 2.20


The short description is, that at some time focus goes from SynEdit (in separate source-editor-window) to ComponentNotebook (in main IDE window, default focused component in main-ide-win)

This focus switch has been observed without WM_KillFocus msg

SynEdit may receive a WM_SetFocus msg afterwards (despite never having been told of loosing it)
(unrelated issue: under gtk2 WMSetFocus seems to be send always twice)

In the end a state as follows is reached:
- SynEdit receives KeyDown/Press/Up events. (indicates it has focus)
- in GTKAPIWidgetClient_DrawCaret (lcl\interfaces\gtk2\gtk2winapiwindow.pp line 511) when triggered for the SynEdit in question, the code in line 602:
    HasFocus := gtk_widget_has_focus(Widget);
evaluates to TRUE (indicates it has focus)

- If Synedit calls SynEdit.Focused (which is TWinControl.Focused it receives FALSE.
This directly contradicts the 2 above observations.

Also the user reports of having switched to the Source-editor-window. But analysing TWinControl.Focused shows that "FindOwnerControl(GetFocus)" returns ComponentNotebook.

If the user has switched to the source-editor window a component inside the source-editor window should be focused. If SynEdit receives keydown, then it should be SynEdit.

To all appearance TWinControl.Focused reports wrong

---
It is not necessarily related to the main-ide-bar. This is simple the window used in the test on the original report. It has not been tested if similar behaviour could provoked with other windows

---
The exact detail from the individual functions called by TWinControl.Focused (when called by SynEdit, in the described situation):
FindOwnerControl(GetFocus)=ComponentNotebook
CanTab=True
WidgetSetClass.CanFocus(Self)=True








Additional InformationThe information can be derived from the logs kons5 and kons6 on bug 0017207
TagsNo tags attached.
Fixed in Revision
LazTarget-
WidgetsetGTK 2
Attached Files

Relationships

related to 0017511 acknowledged GTK2 skips WM_SETFOCUS message 
related to 0017562 closedMartin Friebe GTK2: SetFocus is ignored in certain cases 
related to 0019547 resolvedMartin Friebe XFCE (gtr2) focus issue - Editor loses focus after autocomplete (single button mode in taskbar) 
child of 0017207 resolvedMartin Friebe cursor disappears 

Activities

Zeljan Rikalo

2010-11-06 12:46

developer   ~0042820

Maybe you should test r 28104 where gtk2 focus-in is changed.

Martin Friebe

2010-11-19 13:02

manager   ~0043252

Waiting fo feedback on 0017207

Stephano

2010-12-18 21:53

developer   ~0044359

I have encountered the caret disappearing in the source editor again on 2 occasions. But I can say it is now a very rare occurrence.

David Emerson

2011-01-10 19:53

reporter   ~0045051

I am able to reproduce this consistently. Here is my test case:

- switch tabs using a keyboard shortcut (I use alt+left, dunno if it's a default)
- close tab using ctrl+w
- cursor is invisible on the new tab

I can click, select, type, navigate within the unit using codetools (e.g. ctrl+click or ctrl-shift-down or alt-up) and tab-complete, all with the cursor remaining invisible

If I do a tab-completion that brings up the auto-completion select list, or if I change tabs (incl with keyboard shortcuts) then the caret comes back

I have "use tab history when closing tabs" checked

lazarus 0.9.29-0-20101231 (debian/ubuntu package)
debian lenny, kernel 2.6.26-2, libgtk 2.0-0

Zeljan Rikalo

2012-02-07 13:24

developer   ~0056625

hm..just tested with Lazarus 0.9.31 r35221 FPC 2.6.1 i386-linux-gtk 2 (Fedora 14 32 bit + gtk2 2.24) and cannot reproduce it.

Juha Manninen

2013-04-29 13:39

developer   ~0067263

Is this still valid? I believe it was caused by an old GTK2 version which is not supported any more.

Bart Broersma

2013-04-29 16:13

developer   ~0067269

Did we change minimal supported GTK2 version (was 2.8 AFAIK)?

Martin Friebe

2015-01-26 01:42

manager   ~0080579

No feedback received.

Request for Feedback was noted in parent issue 0017207 0017207:0067293

Issue History

Date Modified Username Field Change
2010-08-24 21:26 Martin Friebe New Issue
2010-08-24 21:26 Martin Friebe LazTarget => -
2010-08-24 21:26 Martin Friebe Widgetset => GTK 2
2010-08-24 21:26 Martin Friebe Relationship added child of 0017207
2010-10-29 11:02 Vincent Snijders Relationship added related to 0017511
2010-10-29 12:37 Vincent Snijders Status new => acknowledged
2010-11-06 12:46 Zeljan Rikalo Note Added: 0042820
2010-11-06 12:46 Zeljan Rikalo Status acknowledged => feedback
2010-11-06 12:47 Zeljan Rikalo Relationship added related to 0017562
2010-11-19 13:02 Martin Friebe Note Added: 0043252
2010-12-18 21:53 Stephano Note Added: 0044359
2011-01-10 19:53 David Emerson Note Added: 0045051
2012-01-15 13:38 Martin Friebe Relationship added related to 0019547
2012-02-07 13:24 Zeljan Rikalo Note Added: 0056625
2013-04-29 13:39 Juha Manninen Note Added: 0067263
2013-04-29 16:13 Bart Broersma Note Added: 0067269
2015-01-26 01:42 Martin Friebe Note Added: 0080579
2015-01-26 01:42 Martin Friebe Status feedback => new
2015-01-26 01:42 Martin Friebe Status new => resolved
2015-01-26 01:42 Martin Friebe Resolution open => unable to reproduce
2015-01-26 01:42 Martin Friebe Assigned To => Martin Friebe
2019-04-22 19:33 Martin Friebe Status resolved => closed