Initial display of grid with client side sorting enabled

[jpmurtha]

It appears that the collating sequence difference between ASCII and EBCDIC may be the reason why the initial display of a grid with client side sorting enabled with an initial sort column that has alpha numeric data could potentially not display the initial row(s).

The client side sorting settings are as follows
* sortable columns = true
* default sort order = ascending
* initial sort column = 2

The attachment(s) show a modified GRID001D and R from PUISAMPLES that represents a load all grid with a max number of rows of 24. GRID001R reads the PRODUCTSP file in ascending sequence where product name is the sort field. RRN and a checkbox have been added to the first column of grid. The initial display has RRN = 1 as the first row and the scroll bar is visually not at the top, indicating that one or more rows are not being displayed (see attachment 1) After doing a page up the scroll bar visually appears at the top and RRN = 19 is displayed as the first row in the grid.

Is this being caused by difference in collating sequence between ASCII and EBCDIC? Is there a way to get the first row, based on initial sort column and default sort order to display when initial screen shows?[attachment=1]EBCDIC-ASCII-3.jpg[/attachment][attachment=0]EBCDIC-ASCII-4.jpg[/attachment]

[Scott Klement]

I'm not 100% sure what you're asking... but when client-side sorting runs, it moves the RRNs along with the data. (If that makes sense?) So if 'ABC ACCESSORY BELTS' is RRN=1 before the sorting, it will still be RRN=1 after the sorting... even if it's no longer the first row in the grid. Therefore, if you use the "subfile record number" property to set to RRN=1, it might not result in positioning at the top of the subfile.

If it's important to position to the top of the subfile (rather than wherever RRN=1 happens to be) then I would remove the "subfile record number" property, and the grid should just default to show the top record.

I don't THINK (unless I'm missing a detail in your post, which is certain poisslbe) that this has anything to do with ASCII vs EBCDIC? (Or, more accurately, Unicode vs EBCDIC, since we use Unicode rather than ASCII). I guess if you are sorting it in the RPG program before loading the grid, and then sorting it AGAIN in the grid itself and they do not match, then that would be a sign of a Unicode vs. EBCDIC issue... but I'm assuming that you're not sorting the data on the RPG side, and just loading the grid and letting PUI do the sort. In that case, it's only sorted by the Unicode values and so there shouldn't be any sort of conflict, right?

[Scott Klement]

FYI.. it is also possible to define your own special grid sorting function, if that is desirable. (For example, if you wanted to sort numbers after letters like they are in EBCDIC...) I don't really think this applies to what you're asking here (because I don't really think Unicode vs EBCDIC was the underlying issue of what you were asking) but just in case it is... you can control that sort of thing by writing your own sort function as documented here:
http://www.profoundlogic.com/docs/displ ... t+Function