Anybody familiar with this? Or is it just me again
A lot of functionality has been added to SW Tables over the years. Sometimes UI changes occur as a result. In this case, the UI while editing a cell was changed to make the behavior similar to that of Notes. This change was made many releases ago.
I do not see this half height behaviour in the notes, not during editing either.
So when was the change made that text is shown in half height during editing revision tables? It is not the case editing BOM tables. So what of the half height performance during editing a revision table is similar behaviour to what? Please clarify your statement, Matthew.
The same sort of editing area (with a white tight fit around the text) is used for both. "Half height" is your reasonably phrased term for how that white area appears when editing text in a table.
Yes, the white area appears in half the available cell height. However, this only occurs during editing the revision tables, not during editing BOM tables or notes. Properties of the cell are in centre text in height, starting left.
As I have moved from SW 2014 to 2018, now running 2019, in my memory, it used to stay in the centre of the cell. Will start up my old system tonight to check. I do experience all kind of weird behaviour using windows scaling of 125% on 4K screens.
Frank, no need to check. You are correct in how you described the current editing behavior. The current behavior during editing is intentional.
Nice answer, heard it many times before. This behaviour is intentional.
- WHY doesn't it occur during editing other tables?
- What is the intention behind this behaviour?
- Why was it introduced and when? Required by SPR or what?
- Intentional Inconsistent?
No, I see it as a glitch, a bug, an inconsistency in behaviour, bad quality, low standards, free programming by huge amount of people, no house-rules or house-style involved.
Please Matthew, provide some more details about this intention.
I actually did already in my original statement.
Who cares where the text is during editing.... Quit making rev tables automatically double height....
Original rev table:
Clicked button to add rev:
Drop rev triangle.... BAM: Double height.
Fine. I'll manually shrink it down to single height:
Now to add rev B... DANGIT back to double height for the whole table!
Fine.... Right-click, Entire Table, Format. Set row height. Should be permanent, right? Nope. Add a rev, everything goes back to double height.
Josh, First, make sure you've saved a template with the height you want for the top revision row. If you still see this problem with your new template, please report the issue. For content-driven tables (BOMs, Hole Tables, Rev Table, etc), the template should properly store the first row's height and use that as the default any new rows created.
My revision tables are locked in row height. That might help....
This annoying behaviour of changing heights of rows luckily is blocked on my system. I do not like automatic changes of size, I like the approach what you see is what you get.
Retrieving data ...