nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Always show column headers when scrolling

goodside

Has the ability to keep table headers visible at the top of a report even when scrolling down through a long list of data been fixed in BIRT 4.4.0? The problem seems to have existed for ages through multiple versions of BIRT according to old forum posts here, and the workarounds just aren't working well enough for me to use.
These workarounds were posted here some time ago, and I have tried both in BIRT 4.4.0, and are as follows with the problems I encountered:
 
1. Using a grid with 1 column and 2 rows, splitting the table so the header is in grid cell 1 and the details are in grid cell 2, then setting the grid cell 2 overflow to scroll.
The problem with this is the report must used a fixed layout and a defined height, causing the report to be too small and generally awkward to read. I need to use auto layout because the reports are viewed on multiple systems. <a data-ipb='nomediaparse' href='http://developer.actuate.com/community/forum/index.php?/topic/34744-how-to-keep-headers-visible-when-scrolling/'>http://developer.actuate.com/community/forum/index.php?/topic/34744-how-to-keep-headers-visible-when-scrolling/</a>

Find more posts tagged with

Comments

kclark

How many different systems do you plan on deploying to? Can you use JavaScript to check for the screen size and the auto adjust the size of your master page. This would keep you from needing to use an auto layout then you could use script to resize the table. I haven't tried it before, but thought I'd throw that idea out. I'll see if I can't work out an example for you

goodside

Thak you for your reply, I will look into getting your idea working as a potential solution, but honestly I was trying to avoid having to add chunks of code to each report, since errors are more likely. I am one of many programmers who creates new and updates old reports on our systems all the time, and keeping track of changes and versions is important. It can get kinda messy if someone forgets to add the extra code or adds it in the wrong way/place, or someone edits it incorrectly/accidentally etc, and we lose time fixing these errors and have to roll-back versions to fix them, something we have to try to do as infrequently as possible.