attached is a screenshot of an embedded QWP. it has about 10 column. one of the columns, 'remark' is a multi line string. the others are simple strings, dates or numeric. the width of these columns is very far from what we'd like. the columns Id, User, Location and SNOMED are all short strings or blank, yet get lots of width. Remark, the only multiline string, is crowded.
what options exist to rectify this? If I put the same text in Clinical Remarks.query.xml, it does reserve space.
<column columnName="Remark">
<isHidden>false</isHidden>
<displayWidth>250</displayWidth>
</column>
Manually setting columns widths is not a great solution when dealing with lots of tables and columns, but it's better than nothing. This fixes that one column, but a number of the other columns are also receiving unnecessarily large width. It seems like perhaps any column that is a lookup is getting a larger width? If this is true, can that behavior be revisited?
Questions are:
1. can i force the column width to increase in some other manner?
2. can i set the width in a more global way, instead of query by query? remark is a column from studyData. I tried to add that same XML to studyData.query.xml; however, it did not work. Should I expect this be inherited?
does anyone have other thoughts or suggestions? thanks for the help. |
| |
| Ben Bimber responded: |
2010-09-27 10:31 |
it definitely seems like string columns, but not integer columns, that are lookups get a larger width. at least for us, this is an unwanted behavior that tends to crowd out other columns. in queries without these lookups, the QWP seems to do a reasonable job of automatically assigning width. |
| |
| jeckels responded: |
2010-10-01 14:50 |
Hi Ben,
Our default width for string columns is, in pixels, 6 times the number of characters that it allows, up to a maximum of 200 pixels. Date/time columns default to 90 pixels, and everything else is 60. This should be based on the data type that we're rendering in the grid, whether it's a lookup or not. For example, if you have a column that's an integer that's a lookup to table and is rendered as a string, we'll use the string width calculation.
I investigated and right now we're only propagating button bar configuration from study.StudyData to the individual dataset tables, which explains why your width setting isn't getting used. I'll enter a bug to make more study.StudyData metadata inheritable.
We can also revisit our width heuristic. The underlying database schema uses a VARCHAR(32) to store participant/animal identifiers, but of course all of your IDs are much shorter, so it reserves more space than needed when rendering.
Thanks,
Josh |
| |
| Ben Bimber responded: |
2010-10-02 06:52 |
hi josh,
if you look in the above screesnhot, all 5 simple text columns got a consistent width, probably 200px based on what you say. the one multi-line column actually gets crushed, which doesnt make much sense.
while certainly the participant Id column could be reduced in size, it's a much more widespread problem than that.
i attached a screenshot of different grids in which labkey does a much better job of distributing width. however, you see that certain string columns get downsized in width, but the lookup columns stay at 200px. could this have something to do with labkey expecting to use a different display column and/or not knowing what width to expect from the display column? does labkey have some sort of process by which it tries to fit the grid to screen width and certain columns get their width cut first?
the main point is that while most of the time strings get 200px some of the time they dont. it'd be nice to figure out how to make more of them do that. |
|
| |
|
|
column widths.png
columns.png