Item14004: EditRowPlugin textarea doesn't honor the dimensions.

When formatting a EditRow table with a textarea, the (row)X(column) size option is not working properly as it did in the EditTable Plugin.

I used the following format:

textarea, 5x100, Description

The "5" rows works, but the "100" columns does not. No matter the number of columns I specify, the horizontal size of the textarea never changes.

3x10	5x20	10x50
3x10	5x20	10x50

-- MichaelShaver - 04 Mar 2016

The feature fails when

• Editing the row
• Editing the table

However clicking the corner 'stain' in the cell opens the expected size textarea.

-- GeorgeClark - 04 Mar 2016

I don't know why this bug report was classified as enhancement. The plugin is totally broken when it does not respect the documented format settings. I just tried to enable this plugin instead of the TablePlugin and noticed the same and came here and saw the same issue raised.

I changed the example above to something reasonable. You cannot have a 1000 character wide field in practical. And 5 rows of 1 char is also nonsense. The example should reflect a real use case

It seems the plugin defaults to a certain width and ignores the format string. And with the height it seems to accept the 3 and 5 but not the 10. And the height of 10 is also ignored in single cell edit mode.

it seems this plugin choses the format as the wind blows

When you edit the individual cells the width seems to be ems and not chars because the font used is not a fixed pitch font.

-- KennethLavrsen - 04 Mar 2016 - 13:10

It was marked enhancement because that's the default in the form and nobody classified it.

Looking in the generated html using firefox debug tools, the textarea does have the correct width set. So this isn't a simple issue on the server side that I can see.

-- GeorgeClark - 04 Mar 2016

Apologies on the bug report not being entered properly, this is my first bug report. We use 5x100 in a reporting topic and that's the only setting I've ever used so I stayed with what I was familiar with and just added some zeroes.

Do I need to change anything?

-- MichaelShaver - 07 Mar 2016

There was nothing wrong with your report. Thanks for reporting, in fact! I have just committed a fix that should land in the next patch release.

-- JanKrueger - 07 Mar 2016

I do not see any check-in references for this bug item. Were the git hooks not working or was it not checked in?

Thanks for the fix in any case.

And thanks to Michael for the bug report.

-- KennethLavrsen - 30 Mar 2016

Reopening to remind to check that the code is checked in AND to add this bug item in the change history in the plugin .txt file. It is a huge bug so it should be flagged in the change history.

-- KennethLavrsen - 30 Mar 2016

I find Commit 29f9fec57b8968e74ef876a80010f5c95ebaa12c and 61df8e97e897ee658bad2624179d7da5236d90ae

-- KennethLavrsen - 30 Mar 2016

Looks like something broke down in the github push to Tasks web. They were logged as status 200 - applied., in the github hooks diagnostics, but were not applied to the task. I re-processed the push events and the task was updated correctly.

-- GeorgeClark - 03 Apr 2016

Commenting is disabled while not logged in