textarea editor does not honor attr rows=?

[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

[ralph1996]

Here is another example that shows how the new editor is definitely a step back in our situation.

As mentioned in the previous reply, the grids embedded in the page may have few or no rows in them. In the case where there have no rows and you add the first row, the grid height is very short.  When you open the editor there really is only room for slightly more than one line in the editor.  So when you try to type multi-line text you still only see a single line and there is not even enough vertical clearance for a scroll bar.  See the attached images.  The first is an image of the empty grid.  The second shows an added row and the editor open.  I have typed 5 lines into the editor.  You see about 1.5 lines at the end and there is no scroll bar.

After saving the grid is resized to show the entre content - but the initial edit is terrible.  This is a very common case for our users  as often the records initially contain no content in the grids until they add the content.

[paramvir]

Thanks for your feedback, I would look into the possibility of adding it as an option.

[ralph1996]

Is there any progress on this issue.  This is having a considerable effect on our application and users are having a difficult time entering their data.

[paramvir]

Yes, please check this example:

https://paramquery.com/pro/demos/edit_multiline

[ralph1996]

Thank you very much.  This is much better, however there are a couple of issues in the implementation.  Using your demo example the "Manual" column (which is the most consistent with the original behavior) does not properly set the editor width based on the columns attribute

Code: [Select]

               
title: "Manually resizable editor", width: 200, dataIndx: "ShipAddress3",
                editor: {
                    type: "textarea",
                    attr: "rows=5 columns=28",
                    style: "resize:both;"
                },

In the demo page you can set columns to any value yet the editor opens at the same width no matter.  It appears the containing div for the editor has a fixed width set.  This div can be resized if you enable the resize style, but the initial div width ideally would be set to the width of the column.

The textarea attribute is set correctly:

Code: [Select]

<textarea class="pq-editor-focus  pq-cell-editor " rows="5" columns="28" style="resize:both;" name="ShipAddress3"></textarea>

However the pq-editor-outer div has a width set that is not tied to the number of columns you set in the attributes.  If you omit the columns attribute there is no change.  I have included an image of the elements and width property from the Chrome devtools window with the original 28 columns as well as when it is 200 columns.  You can see the width of the containing div is the same.

Finally, if you do use the resize handle to resize the width of the editor, the editor does resize but the width of containing pq-editor-outer div actually resizes larger than the textarea leaving a non-transparent white artifact over the grid.  It disappears once editing is complete, but it is a little odd.  If you drag the resize handle left and right a number of times without releasing you will see that div size increases to be larger and larger.  I have attached an image of the issue.

[paramvir]

In the demo page you can set columns to any value yet the editor opens at the same width no matter.

Correct attribute is cols instead of columns. It has been corrected in the demo.

if you do use the resize handle to resize the width of the editor, the editor does resize but the width of containing pq-editor-outer div actually resizes larger than the textarea leaving a non-transparent white artifact over the grid.

https://paramquery.com/pro/demos/edit_multiline

It's not observed at my end, checked in Chrome, FF & Edge. Have you done any css customizations at your end.

[ralph1996]

Thank you for the update.

I don't see the artifact now either.  The image I sent was taken from your edit text demo page.  I did not make any modifications.  But, running the demo now I do not see it.  So I guess there was some difference at that time.  I will let you know if I see it again.

[ralph1996]

One last question.  Is there any way to make the "Manual" editor open to the full width of the cell if you just supply the rows attribute?  The problem is that we define the column widths in pixels, but of course with flex the column widths can change.  So setting the cols attribute initially in the column model will not keep the width of the editor the same as the width of the cell.

I imagine we could do something in the cellClick event or possibly editorBegin (although it is probably too late then) to get the cell width and adjust the colModel attributes.  However, this still requires converting pixels to cols which is pretty inaccurate.

Ideally the default width of the editor would be the full width of the cell.

[paramvir]

Currently it's not feasible with manual resize, I would look into it for future enhancement.

[ralph1996]

OK Thank you.

If this gets in (we would love that) ideally it would be nice to have an option to open a manually sized editor at either a minumum height / width or at the size of the cell if it is larger in either dimension.  Effectively the ideal is to specify minWidth (minCols) and minRows and if rows or width (cols) is not specified then open to match the size of the cell in that dimension as long as it is at least the min value for that dimension.

This is the wish list, if it is possible.  But we will take any improvement we can get.  Thanks!