Project

General

Profile

Actions

Bug #1029

closed

WTableView second scrollTo not working properly

Added by Łukasz Matuszewski over 12 years ago. Updated about 12 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
10/18/2011
Due date:
% Done:

0%

Estimated time:

Description

In attachment is an working example showing that when i move slider by mouse it slides WTableView but not properly. From my point of view the second call to scrollTo in event loop processing signals from WSlider doesn't work. One workaround is to use WSlider::sliderMoved() which works fine. The mentioned scrollTo happens inside this sample code:

      void Prezentacja::slt_sliderValueChanged(int page)
      {
        int page_scroll_to = this->m_slider->maximum() - page;
        this->m_wtv->scrollTo(this->m_wtv->model()
                        ->index(page_scroll_to * this->m_rows, 0), WTableView::PositionAtTop); 
      }

You have to run app to see that this bug really happens.

Hope to see a bug fix soon.

There is also a bugfix to Firebird.C driver for FirebirdSQL (missing IBPP::Database::Connect(), which is required to allow normally working).


Files

Prezentacja.zip (28.9 KB) Prezentacja.zip Łukasz Matuszewski, 10/18/2011 02:56 PM
Firebird.C (20.6 KB) Firebird.C Łukasz Matuszewski, 10/18/2011 02:56 PM
bug1029.zip (3.34 KB) bug1029.zip bug1029.zip Pieter Libin, 11/16/2011 12:04 PM
Prezentacja.wt.exe.jpg (12.1 KB) Prezentacja.wt.exe.jpg Łukasz Matuszewski, 11/25/2011 09:43 AM
Actions #1

Updated by Koen Deforche over 12 years ago

  • Status changed from New to InProgress
  • Assignee set to Pieter Libin
  • Target version set to 3.2.0
Actions #2

Updated by Pieter Libin over 12 years ago

Hi,

when I try to run your example, I get an exception because no database is created yet,

do you think it is possible to create an example that does not rely on the database?

kind regards,

Pieter

Actions #3

Updated by Łukasz Matuszewski over 12 years ago

Hi,

Hi,

when I try to run your example, I get an exception because no database is created yet,
do you think it is possible to create an example that does not rely on the database?

kind regards,

Pieter

There is comment in code saying /*connection parameters*/ - which i think should be /*connection parameters - PLEASE FILL */

Prezentacja::Prezentacja(const WEnvironment& env) : WApplication(env), m_firebird(/*connection parameters*/)

I think it can be done by mocking (or should I say, rewriting) NazArtNazAlbItpModel, and in there generating about 1000 of records randomly. Other ways may apply to, but I don't have thoughts right now...

Sorry for late reply - I have lot on lot of work these days.

Thanks for believing me that there is a bug.

About the Opera Browser - in version 11.60beta they fixed theirs bug / not Wt C bug about generating WLink urls in apps deployed within a prefix after the hostname:port part like in http://synat.eti.pg.gda.pl/wt/SyNaTPG.wt

BR

Lukasz Matuszewski

Actions #4

Updated by Pieter Libin over 12 years ago

I've simplified your example so it does not use a database anymore,

but I'm not able to reproduce the problem.

Can you take a look at the test case I created (attached: bug1029.zip),

and provide us with a scenario to reproduce the issue?

Actions #5

Updated by Łukasz Matuszewski over 12 years ago

Ok i will try.

Actions #6

Updated by Łukasz Matuszewski over 12 years ago

I have attached a screen shot of playing with you simplified example... I only have changed the line which sets how many rows you will test from:

  int rows = 1000;

to

  int rows = 10000;

and then played with slider a little bit (just by simply moving to position as shown in screen shot).

Hope it helps to reproduce the bug...

BR,

Lukasz Matuszewski

Actions #7

Updated by Koen Deforche over 12 years ago

  • Target version changed from 3.2.0 to 3.2.1
Actions #8

Updated by Pieter Libin about 12 years ago

  • Status changed from InProgress to Resolved
Actions #9

Updated by Pieter Libin about 12 years ago

  • Status changed from Resolved to InProgress
  • Assignee changed from Pieter Libin to Koen Deforche
Actions #10

Updated by Koen Deforche about 12 years ago

  • Status changed from InProgress to Resolved

Hey,

The remaining bug seems to be a bug in Chrome, miscalculating the height of the WSlider.

I've implemented a workaround but it is clumsy...

Regards,

koen

Actions #11

Updated by Koen Deforche about 12 years ago

  • Status changed from Resolved to Closed

Fixed in 3.2.1

Actions

Also available in: Atom PDF