General Category > Bug Report

textarea editor does not honor attr rows=?

(1/3) > >>

ralph1996:
In previous version setting the colModel.editor.attr = "rows=5" would open a textarea with 5 rows in which to edit even if there was no text or a single line of text in the cell.

In recent versions the editor opens to the height of the cell only.

Is there any way to allow the textarea to pen to a specific number of rows in the current version? If not this seems like a regression.

ralph1996:
Just wondering if there is any recourse for this issue.  It was reported almost a month ago.

Thank You,

ralph1996:
Attached are examples of the behavior difference. 

First image is ParamQuery 3.x behavior.  This creates a floating text area that is not restricted by height.  The second image is how it looks after typing a few rows into it.

Third image is ParamQuery 7.5.  You can see the text area is height restricted and does not contain the ability to drag resize the area.  The fourth image is again after typing a few rows into it.  As you can see it is limited by the containing div of the grid.  In this case the textarea is inserted into the DOM within the grid.

The previous behavior is much more flexible as you can create a textarea that floats above the grid and is not constrained by it.  The issue that I see is that the textarea element ends up having its height set to the height of the cell and max height set to the height of the grid.  And since it is embedded in the grid DOM it cannot expand beyond the boundaries of the containing div.

The Notes column is defined as follows:

dataIndx: "Notes"
dataType: "html"
doExpand: true
doFlex: true
editModel:
  clicksToEdit: 1
  keyUpDown: false
  saveKey: ""
editable: true
editor:
   attr: "rows=6"
   select: true
   type: "textarea"
render_Notes: ƒ (grid, ui)
title: "Notes"
validations: [{…}]

paramvir:
This is not a bug but replacement of older multiline text editor with a new and better editor.

Under new setup the multiline editor auto expands as the text is entered in it thus making attr rows=? reduntant.

There are few edge use cases where the old setup may seem better but that's a tradeoff between an overall better editor versus old setup.

You can increase the grid height if/when you need a larger editor without scrollbars.

ralph1996:
Can you explain what the new benefits are? In our opinion from the images above, the old editor is much more flexible.  These are the benefits we see:

1. The editor is displayed in a much more defined manner with clear borders etc.  We can probably work around that with css to make it more obvious.

2. The initial editor can be opened to a larger height than the contained contents - which makes it much more obvious to the user that this is a multiline editor as opposed to a single line editor.

3. In shorter grids (as displayed in the images) The editor can still open to a consistent height and is not limited to the height of the grid.  This is where the auto-expand option falls short.  Yes, it expands as you type, but in a single row grid (which is the case with many of our grids) it is very limiting.

4. The user has the option of increasing the editor size using the resize handle.  They can even increase it horizontally to make the editor taller and wider.

In our application we use the ParamQuery grid to embed many grids in our pages.  We use it for our main lookup pages as well, but each record when opened in our detail view contains many sub-grids. Often those sub-grids only have one or two rows in them.  These are the grids where we use editors extensively so this change has a material effect on our application.

In our opinion we so no benefits to the new editor.   It would be ideal if we could have an option to use the old behavior. 

Thank you

Navigation

[0] Message Index

[#] Next page