Opened 14 years ago

Closed 12 years ago

#98 closed bug (fixed)

ListView behaves weirdly inside a tabview

Reported by: jackburton Owned by: stippi
Priority: normal Milestone: R1
Component: - General Version:
Keywords: Cc: diver
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

This can be seen mostly in the "Time" preference application.

  • Open Time
  • Switch Tab to "Time Zone"
  • Switch Tab to "Settings"
  • Switch Tab to "Time Zone"

And there you are. ListView is empty.

A minor variation of the same bug:

  • Open Time
  • Switch Tab to "Time Zone"
  • Click inside the listview
  • Switch Tab to "Settings"

The application will hang completely, and clicking on the window "close" button won't work either.

Seems we have some problems with detaching/reattaching views. This started happening around rev. 15851

Change History (12)

comment:1 by korli, 14 years ago

* Bug 216 has been marked as a duplicate of this bug. *

comment:2 by korli, 14 years ago

Cc: fredrik.ekdahl@… added

comment:3 by jackburton, 14 years ago

The second variation doesn't happen anymore. Moreover, the overall behaviour seems improved lately, although the listview still seems to scroll out of the visible region when tabs are switched.

comment:4 by jackburton, 14 years ago

I think I found the problem: The scrolling state isn't synched between client and server when a view is detached and then reattached. The app_server always resets the fScrollingOffset to 0,0 when a layer is created, while the client could have a different scrolling offset.

comment:5 by axeld, 14 years ago

Owner: changed from bpmagic@… to stippi

comment:6 by axeld, 14 years ago

I've added the scrolling offset to the BView/ViewLayer creation in hrev16997, but it doesn't completely solve the issue, just improves it a bit.

comment:7 by diver, 14 years ago

Cc: diver added

comment:8 by jackburton, 14 years ago

I've noticed that the listview is scrolled correctly now, although it's not invalidated when you switch to its tab for the second (and subsequent) times, for some reason. Covering the listview with another window, in fact, trigger an invalidation and the items are shown correctly.

comment:9 by ekdahl, 13 years ago

Cc: fekdahl@… removed
Platform: All

comment:10 by jackburton, 12 years ago

I've investigated this a bit... I added some printfs() in ListView::Draw(). When you switch the tab (BTabView::Select()), Invalidate() is called on the view, then ListView::Draw() is called with an invalid BRect. Looks like the scrolling offset is ignored in some place. The weird thing is that this doesn't happen the first time the view is attached. Note that this doesn't happen with BListView only, but with every scrolled view inside a BTabView (also with Terminal, for example)

Draw() called with BRect(l:0.0, t:462.0, r:97.0, b:159.0) Bounds() is BRect(l:0.0, t:462.0, r:97.0, b:611.0)

comment:11 by stippi, 12 years ago

Status: newassigned

comment:12 by stippi, 12 years ago

Resolution: fixed
Status: assignedclosed

Fixed in hrev21900.

Note: See TracTickets for help on using tickets.