Label scrollbar doesn't always allow you to scroll far enough to read the entire label
Issue #244
closed
This happens for both columns and rows. Sometimes the scrollbar hits the end and some labels' ends are not visible. And sometimes, the scrollbar is way bigger than the longest label. I have been looking into this already and have been printing out the size of the scrollable area and the size of the longest string (calculated inside LabelView's updateBuffer) and there's definitely a discrepancy. As a concrete example, the longest label will be reported as 280, but the scrollable area size is 224 (which was the previous font size's longest label length). Other times, when the scroll area (of the row labels) is way bigger than the longest string, its size has been 448 when the longest string is 168. Incidentally, 448 is also the value of a variable called stringX, whose purpose I have not yet looked into.
@TreeView3Dev, if you can provide any insights on this, I'd appreciate it - but don't do anything. I've already got a number of changes. For one, I fixed a bug where it was calling getUsedPixels when it should have been calling getAvailablePixels to use to get the last visible data index. When fully zoomed out, I should have been getting data index 132, but was getting 118. Once I made the fix, I was getting 132.
Comments (10)
-
reporter
-
reporter
So the 448 is the value set for the width of the RowLabelPanel when data is first loaded (at least, when it's just the zoom hint). I haven't been able to figure out where the value comes from, despite catching when it is being set. It's not the width of the hint string (it's smaller). It's not the width of the longest row string (much smaller). I have reset the prefs and that 448 value still gets set, so it's not from the prefs. I suppose I could change the size of the window and see if the value changes.
-
reporter
I tested starting up treeview using a different saved window size and it did not affect the 448 value, but I suppose the 448 is a trivial issue as long as I can get the pane to revalidate (so as to not be one font size behind). I'm going to look into the series of events that happens upon clicking the zoom button.
-
repo owner
Ok thanks for the extensive info @hepcat72. I'll take this one up along with the other label issues (inconsistent scrolling etc.) if you don't mind. Would you approve if I reassign the issue to me? Seems indeed like a missing update call or something similar. Seems like the scrollbars are not being noticed when resizing the labels at some point (which of course changes the panel size).
-
reporter
I solved it just now actually, using a call to setPreferredSize in LabelView. And I think I know why some of it was happening. I think it was resizing to the grey boxes.
-
reporter
- changed status to resolved
Added a call to setPreferredSize() in updateBuffer in LabelView which seems to have solved the problem.
-
reporter
I implemented the change in my current branch that I'm experimenting on. I can cherry-pick merge later if no one likes my "experiment".
-
reporter
- changed status to closed
Merged to master.
-
reporter
- changed component to General interface
-
reporter
- removed milestone
Removing milestone: General interface (automated comment)
- Log in to comment
- Assignee
- Type
- Priority
- Status
- closed
- Component
- General interface
- Milestone
- –
- Version
- alpha03
- Votes
- 0
- Watchers
- 2
A bit more info... Still not sure about the case where the size of the pane is way too large, but the size of the pane is definitely a step behind a change in font size, whether you're increasing or decreasing the font size. The pane size will adjust when something else happens. So far, these changes will correct the pane size:
So it seems like there's either a revalidate or repaint missing somewhere... still not sure. Looking to see if I can find it. Also, I will test to see if the large pane size will correct itself using any of these events.