Project

General

Profile

Actions

Bug #14473

open

WDialog positioned aside widget incompletely handles focus

Added by Michael Seibt about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
High
Assignee:
-
Target version:
-
Start date:
04/15/2026
Due date:
% Done:

0%

Estimated time:

Description

Affected: WDialog::positionAt(WWidget*, Orientation) of Wt 4.13.0 (and former versions, checked down to 4.11.4)
Keyboard events still go to the main application (to both the global handlers and to the previously focused widget)
As long as the dialog is popped up using WDialog::positionAt(const WMouseEvent&), it works well - but only until WDialog::positionAt(WWidget*, Orientation).
A WFormWidget like WLineEdit can always be focused and used. But keyboard input does not invoke the connected handlers.


Files

main.cpp (10.9 KB) main.cpp Michael Seibt, 04/16/2026 09:12 AM

Related issues 1 (1 open0 closed)

Related to Improvements #14494: Use css anchor for WWidget::positionAt()Review04/27/2026

Actions
Actions #1

Updated by Michael Seibt about 1 month ago

"But keyboard input does not invoke the connected handlers."

Correction: This last statement was incorrect. Actually, two widgets receive the keyboard events.

STR:

  • run attached main.cpp
  • hold Ctrl and right click into a table cell of the first WTableView --> A WDialog pops up at the mouse position as intended.
  • press Escape --> "ed.keyWentDown 27 focused" is traced and popup is closed as intended.
  • press Space --> A WDialog pops up below the cell as intended.
  • press Escape --> "ed.keyWentDown 27 focused" is traced and popup is closed as intended. But also "tv.keyWentDown 27" is traced. Wrong.
  • hold Ctrl and right click into a table cell --> A WDialog pops up at the mouse position as intended.
  • press keys --> Each time both "ed.keyWentDown focused" and "tv.keyWentDown " is traced. Broken. Does not recover.
Actions #2

Updated by Romain Mardulyn 19 days ago

Actions

Also available in: Atom PDF