Bug #5470: WTableView::selectionChanged() signal isn't emitted after upgrading from 3.3.4 to 3.3.6 - Wt - Redmine

Actions

Copy link

Bug #5470

closed

WTableView::selectionChanged() signal isn't emitted after upgrading from 3.3.4 to 3.3.6

Added by Kayra Akman over 7 years ago. Updated over 6 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Roel Standaert

Target version:

Start date:

01/02/2017

Due date:

% Done:

Estimated time:

Description

I use WTableView is with the following selection properties:

table->setSelectionMode(Wt::SingleSelection);
table->setSelectionBehavior(Wt::SelectRows);

WTableView::selectionChanged() used to be emitted with 3.3.4. WTableView::selectionChanged() isn't emitted anymore after upgrading to 3.3.6. I had to connect to WTableView::clicked() signal.

Files

Download all files

tableview_test.cpp (2.43 KB) tableview_test.cpp		Kayra Akman, 01/05/2017 07:17 PM
tab2_table.png (40.7 KB) tab2_table.png		Kayra Akman, 04/15/2017 04:04 PM
tableview_test_2.cpp (2.42 KB) tableview_test_2.cpp	Added WTableView to Tab 2	Kayra Akman, 04/18/2017 10:02 AM

Actions

Copy link

Updated by Kayra Akman over 7 years ago

File tableview_test.cpp tableview_test.cpp added

To reproduce the regression "progressive-bootstrap" should be enabled.

Actions

Copy link

Updated by Roel Standaert over 7 years ago

Status changed from New to InProgress
Assignee set to Roel Standaert

It looks like the issue is that the mousedown event on WTableView does not arrive when using progressive bootstrap.

Actions

Copy link

Updated by Roel Standaert over 7 years ago

This is due to the WTableView being rendered as a plain WTable initially. It is never updated to the proper Ajax-based implementation. I'll look into making this transition possible.

Actions

Copy link

Updated by Roel Standaert over 7 years ago

Status changed from InProgress to Implemented @Emweb

Actions

Copy link

Updated by Roel Standaert over 7 years ago

Status changed from Implemented @Emweb to Resolved

Actions

Copy link

Updated by Roel Standaert about 7 years ago

Status changed from Resolved to Closed

Actions

Copy link

Updated by Kayra Akman about 7 years ago

File tab2_table.png tab2_table.png added

Unfortunately this issue is not fixed with Wt 3.3.7. It should be reopened.

The fix for this issue fixed only how WTableView in Tab 1 is rendered, i.e. that it is properly rendered as a WTableView. The WTableView in Tab 2, which is loaded lazily, is still rendered as a table and, therefore, only the clicked() signal is received not selectionChanged(). Note that lazy-loading is the default way of adding a tab to WTabWidget.

The attached screenshot shows the WTableView in Tab 2 of the test application attached to the original report.

Some remarks:

Progressive bootstrap is enabled. When it is disabled, WTableView in Tab 2 is rendered properly and selectionChanged() is emitted.
Issue reproducible in a secondary WTabWidget tab which is loaded lazily.
Wt built today (15.04.2017) from the master branch including all the commits after the 3.3.7 release.

It is the combination of progressive bootstrap and lazy tab loading that leads to this issue.

Actions

Copy link