Can GRID columns be made UNSORTABLE?
We would like to make them unsortable, because when data is loaded into the GRID, certain rows are grouped together.
These rows represent service lines of health claims.
If a sort is performed on a column, then the service lines of DIFFERENT claims get mixed up.
Can GRID columns be made UNSORTABLE?
Moderators: Susan Smith, admin, Gabriel
There isn't currently any way to prevent sorting on a grid, or even a way to determine if the user has sorted the grid (so that you could at least keep it sorted the way they wanted during a populate command).
It makes it so that grids are a little confusing to end users when they first are introduced.
They are still a very powerful tool, especially when combined with SEARCH controls.
The best advice I can offer is to add a column that shows the Health Claim code (or whatever the field is that they are grouped by.) Then, with training, the end user can at least learn to resort them on that column when they need to see health claims together.
Another way you might be able to get around the problem is to use two listviews to show the data. Have one listview that shows all the Health Claims in the file, but only one line per health claim. On that screen, the user selects the health claim and clicks a button that takes them to another screen with a listview showing only the service lines for that specific health claim.
A third alternative is to at least make the training easier for the user, by placing a button on the screen that they can click whenever they want to resort the grid to its original order.
An easy way to sort a grid to its original order is to populate it with the "+" flag and no data (an empty array$). This forces the grid to "unsort itself" without actually adding any rows to the listview. This way you don't even have to show them the column that the rows are grouped by.
We definitly need to be able to prevent sorting on grid columns, and it would be really nice to at least have a way to find out what they sorted it on, so that we could return it for them. But for now, with a little training and some careful program structuring, Grids are still a very powerful and useful tool.
Gabriel
It makes it so that grids are a little confusing to end users when they first are introduced.
They are still a very powerful tool, especially when combined with SEARCH controls.
The best advice I can offer is to add a column that shows the Health Claim code (or whatever the field is that they are grouped by.) Then, with training, the end user can at least learn to resort them on that column when they need to see health claims together.
Another way you might be able to get around the problem is to use two listviews to show the data. Have one listview that shows all the Health Claims in the file, but only one line per health claim. On that screen, the user selects the health claim and clicks a button that takes them to another screen with a listview showing only the service lines for that specific health claim.
A third alternative is to at least make the training easier for the user, by placing a button on the screen that they can click whenever they want to resort the grid to its original order.
An easy way to sort a grid to its original order is to populate it with the "+" flag and no data (an empty array$). This forces the grid to "unsort itself" without actually adding any rows to the listview. This way you don't even have to show them the column that the rows are grouped by.
We definitly need to be able to prevent sorting on grid columns, and it would be really nice to at least have a way to find out what they sorted it on, so that we could return it for them. But for now, with a little training and some careful program structuring, Grids are still a very powerful and useful tool.
Gabriel
The latest 4.2 version has this feature:
With respect to:
With respect to:
- PRINT FIELDS "10,20,GRID 10/80,HEADERS,[hdrs],1520": (MAT HEADINGS$, MAT WIDTHS, MAT FIELD_FORMS$)
Tried this out and it works - however....
The syntax is FORMS$(x)="C 12,X^NOSORT[attribute]"
If the X is used to force an enter/grid exit on each cell
The statement prevents BR from sorting on that column and so to prevent sorting of the entire grid the "^NOSORT" must be in each cell of the FORMS$ array.
Since the array can not be sorted the automatic search, which relies on a sorted column, will not work unless the grid is presorted before display. The column to search on is then limited to the presorted column. If no presort occurs then the search will not work.
An option to get around this is the FNLISTSRCH and FNLISTSRCHN in FNSNAP.dll
30870 DEF LIBRARY FNLISTSRCHN(MAT L,SRCHSTR$,MAT SELECT;STRT,SMASK$) !: ! ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿!: ! ³ Search a numeric matrix for elements that match a string ³!: ! ³ ³!: ! ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ!
FNGEORGE
The syntax is FORMS$(x)="C 12,X^NOSORT[attribute]"
If the X is used to force an enter/grid exit on each cell
The statement prevents BR from sorting on that column and so to prevent sorting of the entire grid the "^NOSORT" must be in each cell of the FORMS$ array.
Since the array can not be sorted the automatic search, which relies on a sorted column, will not work unless the grid is presorted before display. The column to search on is then limited to the presorted column. If no presort occurs then the search will not work.
An option to get around this is the FNLISTSRCH and FNLISTSRCHN in FNSNAP.dll
30870 DEF LIBRARY FNLISTSRCHN(MAT L,SRCHSTR$,MAT SELECT;STRT,SMASK$) !: ! ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿!: ! ³ Search a numeric matrix for elements that match a string ³!: ! ³ ³!: ! ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ!
FNGEORGE