Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ralph1996

Pages: [1] 2 3 ... 6
1
Bug Report / Issue with scrolling when cells have multiple lines in them
« on: February 09, 2021, 04:52:19 am »
There are two issues here.  The first is that if you have a cell with a link aligned to the top of the cell and the cell has multiple lines such that some of the lines are scrolled off the bottom.  Clicking on the link will shift the cell up to the point where the entire cell fits in the view.  However, when this happens the link is moved from where the click occurred and the link is not followed.  I am thinking that if this shift needs to occur, then the coordinates of the mouse click should be adjusted accordingly so it will fall on the same location within the cell when handled.

The second issue is that in the above case, if you have frozen columns.  The shift of the cell to pull it into view only happens in either the left or right of the freeze divider and not both.  This causes misaligned cells in the view.

Both of these issues can be witnessed by making a simple change to the Frozen Columns demo on your site.  Below is the code with two comments showing the change:

Code: [Select]

$(function () {
        var columns = [
            { title: "Order ID", dataIndx: "OrderID", render: renderOrderId }, //*** Add Renderer
            { title: "Customer Name", dataIndx: "CustomerName" },
            { title: "Product Name", dataIndx: "ProductName" },
            { title: "Unit Price", dataIndx: "UnitPrice", dataType: 'float', format: '$#,###.00' },
            { title: "Quantity", dataIndx: "Quantity", dataType: 'integer' },
    { title: "Order Date", dataIndx: "OrderDate" },
    { title: "Required Date", dataIndx: "RequiredDate" },
    { title: "Shipped Date", dataIndx: "ShippedDate" },
            { title: "ShipCountry", dataIndx: "ShipCountry" },
            { title: "Freight", align: "right", dataIndx: "Freight" },
            { title: "Shipping Name", dataIndx: "ShipName" },
            { title: "Shipping Address", dataIndx: "ShipAddress" },
            { title: "Shipping City", dataIndx: "ShipCity" },
            { title: "Shipping Region", dataIndx: "ShipRegion" },
            { title: "Shipping Postal Code", dataIndx: "ShipPostalCode", minWidth: 150 }
];
        var dataModel = {
            location: "remote",
            dataType: "JSON",
            method: "GET",
            url: "/Content/invoice.json"
        }

//*** RENDERER
function renderOrderId()
{
return "<a href='google.com'>google</a>";
}

        var $grid = $("div#grid_freeze_columns").pqGrid({
            height: 500,
            autoRow: true,
            dataModel: dataModel,
            create: function () {
                this.flex();
            },
            pageModel: { type: 'local', rPP: 20, rPPOptions: [1, 10, 20, 30, 40, 50, 100] },
            colModel: columns,
            //selectionModel: { type: 'row' },
            toolbar: {
                style: "text-align:center",
                items: [{
                    type: 'select',
                    label: 'Number of frozen columns: ',
                    options: [0, 1, 2, 3],
                    listener: function (evt) {
                        this.option("freezeCols", evt.target.value);
                        this.refresh();
                    }                                           
                }]
            },
            numberCell: { resizable: true, width: 40, title: "#", minWidth: 25 },
            title: "Shipping Orders",
            resizable: true
        });
    });

If you run this code and scroll the view so that one of the rows is just showing the google link but not the bottom of the cell.  Then click the link - you will see the cell shift up and the link is not followed.  For the second issue you can do exactly the same procedure, but first change the "Number of Frozen Columns" dropdown to0 be set to 2.  CLick on the link will shift only the frozen columns up but not the right side.

2
Bug Report / Re: textarea editor does not honor attr rows=?
« on: January 14, 2021, 03:25:15 am »
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!

3
Bug Report / Integration with DatePicker broken in 7.6
« on: January 06, 2021, 10:45:04 pm »
Using the 7.x Demo page on your site - choose editors and validations.

In the table click on an order date cell.  The date picker will popup.  Choose a new date by clicking on a date. The datepicker will close and the date in the cell remains unchanged.  You can repeat this on other order date cells.

However, if you click on another cell (for example a dropdown cell) and then click on an order date cell and choose a date, the new date will populate.

So the problem in your demos only happens if you have not opened other editors on the grid besides the datepicker editors.

We were seeing this in our application as soon as we updated to 7.6. Version 7.5 worked fine.  So I tried it in your demo page and the behavior was the same.  Your 6.x demos work fine.  In our application clicking on another cell does not clear the issue, so there is something slightly different there.  But since it can easily be reproduced in the demo page it is obviously a regression from 7.5 to 7.6.

This is prohibiting us from upgrading to 7.6 for other features we need (like Manual sizing of textarea editors).

Thank you

4
Bug Report / Re: textarea editor does not honor attr rows=?
« on: January 06, 2021, 10:15:21 pm »
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.

5
Bug Report / Re: textarea editor does not honor attr rows=?
« on: January 06, 2021, 08:22:01 pm »
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.

6
Bug Report / Re: textarea editor does not honor attr rows=?
« on: January 05, 2021, 11:12:44 pm »
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.

7
Bug Report / Re: textarea editor does not honor attr rows=?
« on: January 05, 2021, 05:19:58 am »
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.


8
Bug Report / Anchor Tags in strNoRows do not work
« on: December 31, 2020, 04:02:35 am »
If you include an anchor tag in the strNoRows string, the links do not work.  It appears there is a div overlaying the pq-grid-norows div when it is visible so clicks do not reach it. I worked around this by adding z-index: 1000 to the pq-grid-norows class.

9
Bug Report / maxLen validation is failing on empty text from editor
« on: October 03, 2020, 01:34:17 am »
I have set the validations on a column to be maxLen = 8000.  I have traced the validation code in fn._digestNewRow to the point where it does the validations:

Code: [Select]
                if (validate && column.validations) {
                    if (source == "edit" && allowInvalid === false) {
                        var objRet = this.isValid({
                            focusInvalid: true,
                            dataIndx: dataIndx,
                            rowIndx: rowIndx,
                            value: newVal
                        });

which eventually gets to this code in _isValidCell

Code: [Select]
                               var valid = valids[j],
                    on = valid.on,
                    type = valid.type,
                    _valid = false,
                    msg = valid.msg,
                    reqVal = valid.value;
                if (on === false) {
                    continue
                }
                if (fn = pq.validations[type]) {
                    _valid = value == null ? false : fn(value, reqVal, getValue)
                } else if (type) {

The issue is that with an empty text the value is null so the validation fails.  I have verified above that type is maxLen and reqVal is 8000.

I will say this is somewhat erratic as I have seen cases where it does not generate the error although in most cases it is happening for us.  I assume when it succeeds the value is an empty string instead of null.

The column definition is as follows:

Code: [Select]
dataIndx: "Notes"
dataType: "html"
doExpand: true
doFlex: true
editModel: {clicksToEdit: 1, saveKey: "", keyUpDown: false}
editable: true
editor:
  attr: "rows=6"
  select: true
  type: "textarea"
render_Notes: ƒ (grid, ui)
title: "Notes"
validations: Array(1)
  0:
    msg: "Maximum length is 8000"
    type: "maxLen"
    value: 8000

10
Bug Report / Re: textarea editor does not honor attr rows=?
« on: October 02, 2020, 07:39:11 pm »
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.

11
Bug Report / Re: textarea editor does not honor attr rows=?
« on: October 02, 2020, 07:21:35 pm »
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

12
Bug Report / Re: textarea editor does not honor attr rows=?
« on: October 02, 2020, 01:23:28 am »
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: [{…}]

13
Bug Report / Re: textarea editor does not honor attr rows=?
« on: October 01, 2020, 11:46:21 pm »
Just wondering if there is any recourse for this issue.  It was reported almost a month ago.

Thank You,

14
Help for ParamQuery Pro / Re: autoRow height issue.
« on: September 17, 2020, 07:26:43 pm »
Thank you.  Much appreciated.

15
Any help on this would be appreciated.  Is it possible to have an option to define which behavior you want in textarea editors?

Pages: [1] 2 3 ... 6