This bug is similar to https://getsatisfaction.com/easynth/t… but instead of the triangle element this is about the table element.
I could not reproduce it. Is it always reproducible? I doubt your ForeUI met error and can not work correctly at the time.
I happens if you in the table edit mode have resized each column so that their width is not “Auto”.
It is an intended behavior. Since all columns are set to specific width, ForeUI will not resize any of them, even the whole table is resized.
You will need at least one column to have “auto” width, so it will be enlarged to fit the table. You can double click the column header to set it to “auto” width.
Then I don’t understand why you allow resizing the table, because the feature is useless if all columns are not “Auto”.
I see two options here:
– Either you disable resizing with the mouse and h/w values and e.g. show an error telling the user that resizing is not possible unless at least one column is set to “Auto”
– You allow it and increase the width of all columns evenly.
I would prefer the second option.
We could not allow increasing the width of all columns evenly, since user has specify the number of pixels for each column, ForeUI should respect that input.
In the future, maybe the table column can support percentage value, in that case, ForeUI can resize all columns according to the their percentage.
It is not necessary to disable the table resizing when none of column is “auto” width. The current behavior (table is resized but column is not) allows you to change one column width to “auto” later. If we disable the table resizing, you will have to change the column width first, and then resize the whole table. I bet you will feel even worse if we do so.
The current functionality is not intuitive, and I guess that other users might be confused by this.
How about this?: You add a lock icon and allow the user to specify a width and lock it. Then resizing the table should respect only the locked columns.
Then you don’t have to add the percentage-functionality 🙂
Actually the “unlocked” width in your mockup works just like the percentage value.
We think the priority of this issue is low. If we improve it in the future, we prefer to implement the percentage width solution, which can take HTML implementation as reference.
This question is now closed