Project

General

Profile

Bug #8911

« Previous | Next »

Default focus resolution should NOT be done until window receives focus

Added by Vladimir Tsichevski 4 days ago. Updated 4 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:

8770-window.p Magnifier (1.64 KB) Vladimir Tsichevski, 06/29/2024 07:53 AM

Related issues

Related to User Interface - Bug #8673: Deduce the logic behind OE focus management and implement in FWD WIP

History

#1 Updated by Vladimir Tsichevski 4 days ago

Code example 8770-window.p:

  1. a number of frames with buttons in the root frame.
  2. the root frame is displayed in a dynamically-created window.

In OE:

  1. the window is opened unfocused
  2. no focus update happens: no widgets receives ENTRY or LEAVE events
  3. if the user passes focus to the window somehow, for example, by clicking the window title, then
  4. the focus resolution happens: the root frame and the window receive ENTRY events, no focus is set as the result.

In FWD:

  1. the window is opened visually unfocused (or it is focused and immediately unfocused?)
  2. focus resolution happens: widgets receive ENTRY events then LEAVE events

It seems, in FWD, the newly-created window receives focus first, then focus is removed, so the focus update happen twice.

Also, the focus resolution result is incorrect: in OE no focus is set, while in FWD the first suitable field in the tab ring receives the focus.

#2 Updated by Vladimir Tsichevski 4 days ago

  • Related to Bug #8673: Deduce the logic behind OE focus management and implement in FWD added

Also available in: Atom PDF