Vaadin Version: 23.3.3
I have a fairly complex Vaadin table, ~100 rows, each of which contains ~12 columns, each column containing a layout with ~10 elements. The table is not lazy in any way, and is configured to show all rows at once.
It takes the browser 5+ seconds just to render the table after the request is complete (a topic for a different question) but even once the table is rendered I experience some weirdness when scrolling.
When holding the mouse outside the table, or using the scroll bar, the page always scrolls as expected. But when I hold the mouse inside the table I get inconsistent results. If I have first scrolled the page all the way to the bottom then there appears to be no issue regardless of mouse position. But If I have yet to scroll to the bottom, then the table scrolls in place, pushing rows underneath the header (see screenshot). It's as if the browser/vaadin is not yet completely aware of the size of the table?
Is there something I need to be doing to force vaadin to render the entire page?
Edit: Upon some further testing I noticed even stranger inconsistencies. My table cells have two possible layouts depending on user actions. One is simple, containing: div > span > span. The other is more complex, containing a div > span > span + vaadin-icon + tooltip. The issue only appears when the table is rendered with the "simple" layout. Something about the added vaadin-icon and tooltip seems to make vaadin draw the table without scroll issues.
Related
My application is using a com.vaadin.flow.component.applayout.AppLayout with a header and a drawer (a standard layout inspired by misc. example programs). The lower right content part is populated with VerticalLayouts that have a #Route(value="foobar", layout = MainLayout.class) annotation, so when clicking on one of the "anchors" in the drawer the corresponding view is added.
That works all nice except for one thing that annoys me:
One of my views has four Accordion components (2 containing a couple of labels and a TextArea each, one containing some textfields and a chart. The forth contains some text fields and a button).
When I unfold these accordions then typically when expanding the third or fourth there is suddenly a second vertical scrollbar appearing just inside the outer, normal scrollbar. Already two opened accordions are higher than what fits a typical browser window, but here the size and the scrollbar is adjusted correctly. Sometimes, but strange enough not always, the scrollbar also adjusts properly with three opened accordions. Sometimes already with the 3rd, but definitely always with the 4th accordion that second scrollbar appears. The combination of opened accordions does not seem to play a role, i.e. there is no accordion that ALWAYS triggers that scrollbar appearing.
I find this second scrollbar most irritating and annoying when navigating the page. Any idea what could cause this? And how to force a single scrollbar only?
BTW: I experimented with wrapping the entire content inside a Div but that didn't change anything - the second scrollbar still appears as described above.
I am using Vaadin Flow 14.6.2, the material theme, and custom CSS styling in my application. When loading a grid that has a cell that has content that wraps 5 times, when the grid initially loads the grid rows overlap, truncating the information in the cell that contains wrapped data. Looking at the CSS this is due to CSS "transform: translateY(#px)" setting that is too small onto the Grid's TR (row) tags. As a point of reference, the grid places a translateY of 76 pixels on the second row.
Screen shot of grid with overlapping rows
Selecting a row in the table or resizing the browser will cause the grid to refresh and the translationY value will be recalculated, increasing the translateY value to 118 pixels, and the grid will display all rows with the appropriate spacing.
Screen shot of grid after selecting a row
Is this a defect in the grid where the row offsets are not initially calculated to the correct height?
I am not sure how to debug this further or if there are any workarounds to trigger the grid to recalculate row sizes so that it may display correctly from the start. I tried programmatically selecting the first row and the result was that the first row displayed correctly but subsequent rows were truncated.
I'd try adding a Div element inside the cell using a ComponentRenderer, and put the white-space: normal and word-break: break-word on that element. Since the grid supports adding components of any size, and should adjust row height according to the heighest component, this may trigger initial calculation.
I was able to work around this issue by changing how this page is navigated to. A change was made to a parent view to trigger navigation using an anchor instead of a button. With an anchor a new UI is created and then the grid is added to it, but with the button the existing UI is reused. There is something in the display of the grid on a new UI or something related to the difference in navigation that triggers this problem. Reverting back to using a button is a superior solution as it solves this problem and does not trigger creation of a new UI.
I have a UITableView in Xamarin iOS and the requirements are this:
There are always at most 10 items to display in a table. There may be less (like 3), but never more than 10.
The Table should always show all 10 rows, and the height should be such that the table never scrolls (because it's only 10 rows).
What would be a good way to make sure it always shows all 10 (or shrinks in height if it's less like 3). This table shares the page with some other elements, so it's not the only thing on the screen. You can scroll on this page.
Right now it's showing the first 5 in the view, but I have to scroll to view the rest. Would this be a matter of me setting the height in StoryBoard to be rather high? But if I do this, would the table shrink automatically if it had a fixed height?
Any advice/recommendations? Again, remember it will only be 10 records, so not a lot to manage in memory. I want to use a UITableView because of the customizations and repetition of the cells, etc.
Thanks!
I'm working on a project for a client. It's an iPad pdf reader. The client wants a collection view, but instead of scrolling vertically, he wants it to use a page control.
It's pretty hard to explain, but what I basically want is all the PDFs on the device in a grid, like on the iBooks app. When that grid overflows, I want to use a page control to display the extra elements on a second page (like in the weather app).
My thoughts on this were:
- Create a page control with one page.
- On that page, create a UICollectionView.
- If the number of elements is greater than 9 add a page to the page control and add another UICollectionView, until there are enough pages to display all elements.
However, this seems horribly inefficient, so my question is if there's a better way to do this.
If your goal is to scroll sideways you can just select that in the interface builder when you have the collection view selected. Then you can make the cell as big as you want. You can even enable paging on the collection view.
In the attributes inspector, right under layout is scroll direction. Set to horizontal.
I came across this question. I see that both stickyHeader and scroller works kind of the same in the way that they both keep the header row visible and there's a scroller bar on the side. Could someone please kindly explain the difference between them?
The stickyHeader widget makes the table head "stick" to the top of the browser, or table container (if options are set), window as the user scrolls down the table; this is similar to the sticky menu some sites use for site navigation. Check out this demo especially the last one on that page which is an example of nested tables stacking the sticky headers while you scroll down the document. There is also a css3 version of this widget which uses css3 transforms to position the table head at the top of the browser window.
The scroller widget, on the other hand, has to make a copy of the table header placed above the table, hides the original table header, then makes the tbody of the table scrollable, within a fixed height. So, the browser window position doesn't change which the user is scrolling through the table content, just a scrollable window of content is seen. If you look at this demo, you'll see that the table body is scrollable, but the head does not "stick" to the browser window (unless you set the scroller_jumpToHeader which forces the table head to become visible while scrolling up the document.