How can I make the column width more readable or automatically adjusted to the length of the data in the cell?
Solved! Go to Solution.
@atanghoneycomb
You may want to check this page:
@atanghoneycomb
You may want to check this page:
Hi Levent. Thanks for the great support again, but it seems wide is still kind of too narrow. Is there anyway to customize the width?
@atanghoneycomb
Not a way that I’m aware of. May be @Steve or @Aleksi can say more.
@atanghoneycomb When you have changed the width option, please use “Save & Verify” instead of just “Save”. This will read your data from the data source and try to adjust your column widths.
Does selecting that column width as wide mean that Appsheet tries to fit all contents into the column or just makes the column width a bit bigger?
The reason that I am asking is that the years of my dates in the below columns are cut.
I then moved from Default on some view and Narrow on other to Wide and ensured I selected Save & Verify and the below picture is the result of having Wide selected.
I see Appsheet’s article mentions the following:
Column width has three settings:
I have also noticed what seems to be a bug.
Let me know if you agree.
So I managed to use a bit of a workaround for my above issue.
So I just added the Expiry with a few ___ to force the column to resize as not to cut out the year of my date just because my column name is smaller than my data in the column.
Now I thought that the Appsheet would also use the same logic and do the opposite and reduce the column width if I use a smaller column display name.
Unfortunately this does not seem to be the case.
It seems that the actual column name on the spreadsheet is what is influencing the column width when it comes to narrowing the column, and on the other hand column display name in Appsheet will influence the column width increase
Do you pick up the same situation by you?
So this is an example of what I mean.
I don’t know what criteria the backend uses to determine column width, but one thing I would suggest, where possible, would be to try and standardize the length of the output. For example, you have two date columns with the long form of the month. If you changed it to DD MMM YYYY format, every date will be the same length and therefore AppSheet should have a better time sizing the column.
Hi
I guessing that you are referring to using a virtual column just to have another column that has a DD MMM YYYY that would be better to work with…as I have not seen any other option to format date in date column type than to the “use long date format” toggle.
This would not be the ideal solution for me for the following reasons:
I going to have to stick to my work around then if that is the case.
I see a lot of use cases for Appsheet users to have a similar table view experience as excel with the added value that appsheet brings by connecting multi table etc.
The current table view needs a bit more “refinement” to improve the users experience though.
I think the same applies for other views…like Card View that is not really usable at present , Graphs that are actually quite limited in use.
Views or UI is one of or not the most important facets of an app.
Apps do not exist without them.
I gather that Appsheet seems to focusing a bit more development on their view types if anything is to be presumed from a few comments from @morgan from recent office hours videos.
Appsheet is for every evolving…so I am looking forward what come next with regards to view types!
I wasn’t necessarily suggesting a VC to reformat the date, as I don’t know your data setup. For example, I don’t know if these dates are always entered, selected from somewhere, or calculated on the fly. If these dates are all entered by the user, then I can’t think of anything easier than a VC.
So depending on your data, you could use TEXT([Date]," DD MMM YYYY"). Even if you did have a VC dedicated just to this, it would be negligible on sync time. Even if you did 3 of them for a couple thousand rows. Even more negligible if Delta Sync is on.
Thanks for the advice.
Ok…will use your option for static data, but then rather us my work around if dates need to be adjust by the user.
Out of interest…I often click on the header to quickly sort the data when I need to…I suppose sort this date column with your TEXT expression will not result in a proper sort…Am I correct?
It should. The only problem that might come up for sorting would be its possible its sorts by day numbers and then alphabetically for month name. But the backend, might still treat it as a date for sorting. I have never played around with it in this manner.
Ok, I will check.
By the way does marking a thread as “solved” help you guys in any way with some “virtual points”
or rating or something?
Or is just well designed UI to help other users quickly come to a the solution?
The reason that I am asking is that I pretty sure I have forgoten to indicate on other posts when someone has helped me come to a solutions…and I am starting to think I maybe indirectly “not giving credit where credit was due”, but did not realise that at the time.
Excuse the wierd question…I have plenty of them!
No worries, it’s mostly to help others find the solution that helped you with your problem, so if it is the same as someone else’s they can quickly see the relevant information instead of scrolling through the entire thread. Super useful for some of the mega threads where the solution was one of the first things suggested, rather than the last.
@Michael_Pinto As @Bahbus relied, it’s a good approach to reduce the string length or having a fixed length. There are so many different factors that your app is trying to find and adjust the width. Unfortunately it’s more like trials and errors before you find the best solution in your case.
User | Count |
---|---|
26 | |
25 | |
25 | |
20 | |
19 |