[haiku-bugs] Re: [Haiku] #3897: [DriveSetup] Rescan menu increase vertical scrollbar
- From: "dru_ed" <trac@xxxxxxxxxxxx>
- Date: Sun, 25 Jul 2010 09:26:10 -0000
#3897: [DriveSetup] Rescan menu increase vertical scrollbar
--------------------------------------+-------------------------------------
Reporter: diver | Owner: stippi
Type: bug | Status: reopened
Priority: normal | Milestone: R1
Component: Applications/DriveSetup | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Has a Patch: 0
Platform: All | Blocking:
--------------------------------------+-------------------------------------
Comment (by dru_ed):
I took a closer look and the patch was treating the symptom. The problem
is still caused by fItemsHeight not reaching 0 when all rows have been
deleted. Yes it looks like the code will take care of it with two
instances of "fItemsHeight -= subTreeHeight + 1;" but, unfortunately, the
code doesn't operate like assumed.
In DriveSetup, let's say I have 3 volumes (parents), 2 with partition
tables (children), for a total of 5 rows in the UI. That 5 UI rows (with
two hideable/expandable) is only seen as 3 rows by the code.
That's fine except fItemsHeight includes the height of all 5 UI rows so
when the 3 parent rows are deleted, the space taken up by the 2 child rows
is still reflected by fItemsHeight. This error is compounded with each
successive refresh. You can see now, I think, why simply setting
fItemsHeight to 0 at the end of RemoveRow seemed to solve the problem.
Why doesn't the RemoveRow code fix this?
First, I found FindParent always returns False. I've not discovered why
but it is connected to "*outParent" (in "OutlineView::FindParent") being
NULL (it's "parentRow" in OutliveView::RemoveRow). I suspect this is
related to the 3 vs 5 row problem mentioned earlier. It makes sense for
the 3 parent rows themselves to return NULL since they have no parent.
What does this lead to? The line "if (parentRow)" does not seem to ever be
TRUE, skipping one case of "fItemsHeight -= subTreeHeight + 1;"
The 3 rows, which are conceptually parents, are removed by what is the
"else" code that seemed to have been meant for children, not parents. This
is where the 3 rows are removed and with "fItemsHeight -= subTreeHeight +
1;"
Is it enough to only compensate for the height of children a parent had
when delete? Perhaps, but that may be no better than the patch which set
fItemsHeight to 0, treating symptoms not illness. I'm not facile enough
with the OutlineView code to know if there's a deeper conceptual problem
but I was surprised the UI "parent" rows are removed by "child" code.
I would suggest looking closer at the FindParent call. In particular does
"parentRow" (called "outParent" in FindParent code) act as expected since
the parents are handled as children and if (parentRow) code is not
executed.
--
Ticket URL: <http://dev.haiku-os.org/ticket/3897#comment:16>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
