The added flexibility for the Tag Panel in 2.91e is really great. However, the "multiline" height option is not working as I would expect. Too many lines are shown after specifying more than one line via Options>Tag Panel>Edit. This makes the text box height much greater than expected or needed. For example, specifying two lines for the Comment field shows four lines of height. I would expect to see the scroll button when more than two lines are entered but it does not appear until more than four lines are entered. See the attached screen shots. Specifying three lines actually shows seven lines of height, and so on. I see this effect on both Windows 7 Home and Professional.
It took a little experimentation when I initially tried the feature and I found the Rows refers to the number of equivalent field heights. Eg: 2 = two single line field heights, rather than text lines in the multiline field itself.
This allows the multiline field to align with other fields, though I can see how when arranged vertically it would be less obvious.
Lauren and Florian, thank you for your clarifications. Yes, I misunderstood what constitutes a row in this context. However, my original problem remains: in a multiline box how can I show only two or three lines of text without scrolling? Currently, that is not possible. The box can show one line or four lines or seven. Two lines would be more useful to me because my tag panel is crowded and because I rarely add more than two lines of comments.
I don't care if the height of this control differs from its neighbors because in my case its width will always be the full width allowed by the panel. My guess is that most people who choose the multiline option will also use the full width available, since that minimizes the need to use the scroll button. So I suggest allowing the multiline rows property to correspond to the text lines allowed without scrolling. That would give users better control over text box height with minimal side effects. Please consider this as a future improvement, if it is possible.
I was also expecting that a multiline field shows the X amount of lines from the settings, instead of the number of rows in the panel. In my opinion the way it works highly deviates from most norms. Currently with Segoe 10, when "rows" set to 1 it shows ca. 1.2 real lines, when set to 2, 4.5 lines, with 3 it shows ~7.1 lines, and so on. In HTML, most GUI editors, etc. multiline fields can be set to a fixed height but they can be also set to display a certain amount of lines. I cannot imagine the current implementation is useful for most users. What is the purpose of this decision if it is intended?
Did you make a poll?
I get the information I need the way it is implemented right now. So please deduct my vote from the users that need a different implementation.
The answer was already given by the programmer:
And to be honest: I simply have a look at a multiline field, if it's too small then I edit the properties and increase the value of rows until it fits my requirement.
For me it does not matter how that gets calculated, it is only important to serve the purpose - which it does in the end.
And as no one dug up this topic since January 2019 (two and a half years ago), I do not see that it is really something that bothers
or hinders them to configure the tag panel.
Admittedly, there are different ways to approach a solution, you have described one alternative - which has not been implemented.
Very contrarian answer there. You shouldn't have bothered.
Every one else:
Meanwhile I've found out the scenario which Florian most likely intended: Horizontal panel, e.g. on top or bottom, rather than on the right. The rows setting is taken into account exactly as Florian describes. Rows=2 renders the panel as the same height as with 2 headings + 2 simple line (small to large) next to them. This seems to be the intention.
I still think that the current implementation breaks common conventions and can imagine well most people use the panel vertically but I have no time for polls or such answers.
Very contrarian answer there. You shouldn't have bothered.