I have a ListView inside of a TornadoFX form builder field that can be added to and removed from by some buttons off to the side. However whenever the contents of the list is modified from the buttons, the list moves vertically downwards. The height of the ListView remains the same, but it's almost as if there is padding being generated along the top whenever the content length is modified. The height change is then reset as soon as there is some change in focus, either by clicking on another component in the view, or by unfocussing and refocussing the window.
I've tried to limit the ability for this to happen by enforcing a max height, both on the form field and on the ListView itself, but neither worked.
Using listeners to print out all the values I could think of that would result in this change, I found that the "bounds in Parent" were changing, adding a value of 17 to both the minY and maxY values. I've not been able to determine where this value of 17 comes from.
The current code for the view is here: https://pastebin.com/6qFVvxvP
I also have some images to help visualize what the problem is:
Before removing content:
After removing content:
Related
I'm struggling to figure out how do I make a flow layout panel that has strictly just one column and upon scrolling it adds the controls at the bottom of that column and not make a new column and so on while having it wrap the controls. I can get that If wrapcontents = false. For some reason in my case the scroll bar appears horizontally at the bottom and not vertically at the right side.
How do you make it as explained?
I'm working on a GTK program in Rust (someone can probably answer this if they don't know Rust, as I can figure out how to translate between different bindings and the native C API) via the gtk-rs bindings for which I want to have a non-editable TextView who's contents are constantly updated in my code. I want the user to be able to resize the TextView to any size, after which my code will re-calculate its contents accordingly. Unfortunately, GTK prevents any resize from taking place that would hide any contents that are current in the TextView. I can't use a ScrolledWindow because I don't want visible scrollbars, and disabling the scrollbars on a ScrolledWindow prevents the resizing behavior that I want. I also tried calling set_size_request to set the size to both 1, 1, and 0, 0 after every text change, but this does not change the behavior at all either — the user still can't properly resize the TextView (by resizing the window).
How can I enable the resizing behavior that I want?
Probably this is not possible. What would be the point of resizing the text view smaller, if the user can never see the text that is outside of the viewport because you don't want scrollbars? That seems like it would confound the user's expectation of how such a component would usually work.
Maybe an approach could be that you pick a certain number of lines to show, make that the size of the viewport, and delete the old contents of the text view that scroll outside of the viewport?
I have a paper-dialog-scrollable which is filled with a dom-repeat from a firebase-query. Everything works fine, except paper-dialog-scrollable doesn't scroll to the bottom when firebase adds an entry to the array.
I managed to set a callback whenever the array gets a new entry (basically with an observer on the spliced array, not on the array).
So how do I instruct paper-dialog-scrollable to scroll to bottom from that callback ?
I saw solutions here which don't seem to work.
Thanks for any insight.
As suggested in the link you provided, give the paper-dialog-scrollable some id (e.g pds) and then add the following code:
this.$.pds.$.scrollable.scrollTop = this.$.pds.$.scrollable.scrollHeight;
An element's scrollTop value is a measurement of the distance from the
element's top to its topmost visible content. When an element's
content does not generate a vertical scrollbar, then its scrollTop
value is 0. Learn more about scrollTop.
The element's scrollHeight read-only property is a measurement of
the height of an element's content, including content not visible on
the screen due to overflow. Learn more about scrollHeight.
I have made a demo here: https://plnkr.co/edit/JIZEdd6NoBBnwndbQuFA?p=preview.
I am trying to populate my windows form with new controls and data based on what is read from my database. The left side of the form is a static panel which will not need re sizing but I need to create multiple labels on the right side which requires more space. I added the vscroll control but am having trouble increasing the size of the right side of the form.
To use a scroll-bar will require a semi-low-level implementation where you need to always update the view by repositioning the elements, calculating your scroll-bar in relation to total view, what elements would be visible and so forth.
A better solution in this case will probably be to add a Panel control on the right which is docked (f.ex. Fill) and then set the AutoScroll property to True.
This way you leave all the "low level" stuff to the Panel control and you can add and position the elements you need to the Panel's Controls collection instead.
When I place a ListBox inside a ScrollViewer, if I do not define a Height attribute for the ListBox, it doesn't scroll (aside from bouncing up and down a bit), so elements off the screen are inaccessible. If I set the Height attribute on the ListBox to the actual height it takes up on the screen, it scrolls perfectly. If I don't get the Height exactly right, it doesn't scroll properly, e.g. I might not be able to reach the bottom elements in the list.
When placing other elements in the single column LayoutRoot Grid above and below the ScrollViewer/ListBox, I set the RowDefinition.Height="Auto" on all rows except the ScrollViewer's, which gets "*". The Grid appears to properly allocate space accordingly. Except now I don't know a priori how much space the ScrollViewer/ListBox takes up.
Part A: Why should I have to set the Height on the ListBox, doesn't its (virtual) height vary with the number of elements?
Part B: It appears I have to manually lay out the Grid row heights, then manually re-do them if a fontsize or other style change is called for. Is that the case? That approach seems bogus.
Your problems are caused because you've got a ListBox inside a ScrollViewer. Don't do this.
The Listbox contains an internal ScrollViewer and will (normally) grow to the available space.
By essentially having a ScrollViewer inside a ScrollViewer it doesn't know which one should grow to fit available space and how they should scroll relative to one another.
Let us know what you're trying to do. There is a better way to do it.