UI Problems in grid in edition mode

[martintaal]

UI Problems in grid in edition mode in all browsers in the latest 10.0d version (and also at least in 13-Feb).

With the following html:

https://mega.co.nz/#!0QwQHLID!MT8sYEUm0qy6eFN3EKh45CkIdhkZmgQ--Y37RmlEqs4

if you open

http://localhost:8080/isomorphic/system/reference/IssueTestResizing.html

When you double click a row (go to edition mode) you can notice that the combo icon button is cutted. If you resize the columns, then it is shown.

In our application we have also another issue that can not be perceived in the previous html that is that also once it goes to edition mode, the inputs are moved some few pixels to the left. Once you resize, they go to the proper place.

Here it is also a video showing the issues in our instance and in the basic IssueTestResizing.html example:

http://screencast.com/t/ofg6djnp

Thanks and regards.

[Isomorphic]

This "test case" is a huge file with lots and lots of application code, making it very difficult to determine whether there's a framework issue or just something wrong in your application code.

If you think your issues are due to a framework bug, please put together something more minimal, and we'll check it out.

[martintaal]

The test file is just a standalone html and the 40% is data for the grid and for the most the rest is just columns and fields definition.

It is the same file provided for other issues like:

http://forums.smartclient.com/showthread.php?p=114669

where this file was the only way to prove to you the issue and solve it. (you can see the related in the post)

With 8.3d it works ok with the same file, so the problem we think is in the framework.

Regards.

[Isomorphic]

Hi Martin,
Firstly, we believe we've found the problem. It looks like the code in this file is explicitly specifying the field-properties within the field as field.editorProperties, including setting field.editorProperties.width to the width of the field.

There is framework logic in place to handle sizing ListGrid edit items correctly within their columns (so they fit within the cell).
By having your application code explicitly set the same width on the edit item (using editorProperties) as the width applied to the listGrid field, you're essentially overriding this behavior, so the item is sizing at the width you've specified, which doesn't take into account the cell padding, leading to the "clipping" of the ComboBox icon on the right.
We haven't gone back and performed the analysis to determine which this used to work in 8.3 as this would appear to just be bad usage, and the fact we used to handle this differently doesn't appear to indicate any kind of framework bug or regression.

Secondly, we were able to debug this test case, but it was a difficult and time-consuming process - and ultimately didn't reveal a framework bug. We'd like to take a moment to talk about how you could have simplified this test case to give us something we could work with efficiently.

There are really two things which make this file difficult to debug.
Firstly it is huge, and contains a massive amount of stuff which is not relevant to the problem at hand. Secondly, the code flow is not intuitive to someone unfamiliar with your application, so it takes some time for our developers to determine how the UI is being built, where the DataSources are being created, how they're being customized, what settings are being applied, etc.

It would have been greatly helpful to us if you had taken steps to simplify the test case on your end before handing it off to us. Some things we would have suggested.
- the ListGrid contains a lot of configuration which can be entirely removed (showRecordComponents, showFilterEditor, autoFitFieldWidths, etc). This avoids us spending time looking into those various subsystems to determine whether they're somehow responsible for this problem (they weren't)
- most of the fields can be removed, getting rid of masses of (irrelevant to us) code to define other fields, option dataSource, editor properties, etc
- The dataSource / component field customization logic is non-obvious - there are field definitions in more than one place, and there are loops to build live dataSources from these definitions, customize the fields, apply to the ListGrid, and so on.

If you incrementally simplify each of these things, it should be easy to identify what exactly is causing the problem. In this case you would have hit the issue when applying the entire set of properties from each field to the "fieldProperties" attribute of that field. At this point you most likely can determine whether you have an issue in your application code, or whether the framework is behaving unexpectedly.
If it is something you'd consider a framework bug, you're now in a position to show us a far simplified test case - either the one you've been working in or, better yet, a truly minimal test case demonstrating the problem you've found.
In this case, something like the following would be what we'd consider a minimal test case demonstrating the problem you hit.

isc.DataSource.create({
    ID:"testDS",
    clientOnly:true,
    fields:[
        {name:"businessPartner"}
    ],
    cacheData:[
        {}
    ]
});

var fields = [
        {name:"businessPartner", editorType:"ComboBoxItem", width:200}
    ];
// apply all properties from the field onto field.editorProperites
// This causes the bad behavior as we're explicitly sizing the
// generated SelectItem to be larger than the available space
// within the cell.
fields[0].editorProperties = isc.addProperties({}, fields[0]);

isc.ListGrid.create({
    width:"100%",
    height:"100%",
    canEdit:true,
    dataSource:"testDS",
    autoFetchData:true,
    fields:fields
});

Thanks for your understanding.

Regards
Isomorphic Software