How do I prevent GridBox from always selecting a row in the GridBox?
When you add rows to a GridBox it always selects the first row. How do I prevent this happening?
This is a major issue for me as I am displaying a paged GridBox and the entry the user has selected is may be on one a page that he is not currently displaying....
Thanks
Richard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess it depends upon what you are trying to acheive but it doesn't look like it is possible to not have anything selected in a gridbox at this time.
To get around this you could:
Have the data loading when you display the page that is currently not displaying.
Have a button instead of listening for action/property events in the gridbox.
Use the gridbox checkbox funtionality in conjunction with the action/property event.
Create a custom compound component(from labels etc) to do that functionality.
Alter your thinwire source to provide this functionality in the existing gridbox component.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You could 'cheat' the system by changing the styling for highlight on the GridBox to be the same as for all other lines, thus none would appear to be highlighted to start with, and then use checkboxes...
I thought I had asked in this forum whether an option might be added to GridBox to make the checkboxes behave like radio buttons - ie so only one at a time can be selected, but I can see now that I could get something similar by using the trick above to apparently deselect everything and then use a click listener to change the highlighing style back to something else once the user has clicked on a line in the Gridbox - Hmm, I'll have to go try that out, see if it's possible! (I'll have to use my own flag to ensure that the user has selected something rather than getting the GridBox default by accident as it were...)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You could also exploit a new feature (or bug??) in the latest build by adding an additional row and then immediately removing it which will cause row highlighting to disappear.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just a quick chime in on this. I've been watching this discussion off and on and I just got a free moment to express a few thoughts on this. First, and this may seem odd, but ThinWire intentionally prevents the deselection of all rows in a GridBox. This is not a bug or a failure to implement the feature. As you can imagine, such a thing would be relatively easy to implement. In fact, we went out of our way to prevent such behavior for a couple reasons.
The first reason actually falls back on UI design principles, specifically the idea that you should never let the user do something that they can't undo. So, if a dropdown has absolutely no selection to start with and a user makes a selection, they should be able to unselect it. Since there's no clear way (that a user would figure out) to do that, it's always best to pre-select a default or add an empty option to the drop-down. Thus, ThinWire implements the principal that a populated drop-down must have an option selected.
The second reason is more for the benefit of the developer and falls back on API design, specifically the tenet that you should avoid returning 'null' if at all possible. ThinWire tries to adhere to that tenet as much as possible, so you'll notice that there are very few cases in the API where you can actually get a null from a method call. All strings always return empty strings and most inner objects are pre-initialized or initialized on demand, to prevent you from having to do null checking. The same concept carries over to drop-downs. Do you want to have to do this everytime you work with a dropdown?
if (row.isChecked()) {
//... do something useful with the row
}
Sure, it's minor... but if you do lots of gridbox operations, those null checks can really pile up. What does everyone think?
-Josh <G>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-11-20
1) You have to check for null already now for gridbox.getSelectedRow() if you dynamicly fill the gridbox and it is possible that it is empty.
2) What about keeping the current behavior as default and add an additional method "forceUnselectAll()" (or something like that) and delegate the responsibility for checking null to the api-user after doing such a "hard" unselect.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-11-20
3) A general switch "setAutoSelectRow(true/false)" would be much more convient for api-users but may be not so easy for the api-developers because the switch must be considered every time autoSelection is done now (adding the first row, deleting the selected row, may be more?). Defaults to true to preserve current behaviour.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I really dislike current behavior which seems to me absolutely unnatural. If it like going to shop and to be forced to by something :) And deselecting a row in UI may be done in very natural and intuitive way - just click selected row once more. Add additional check for null does not bother me at all. There is nothing weird about nulls and if something naturally may be null let it be. Anyway better then ugly substitutes/
Regards,
Oleksandr
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If this topic is expanding to the general behavior of the gridbox, then the standard (Microsoft) behavior is to add control and shift key interpretations to the mouse clicks when selecting/deselecting rows. If a row is selected, using the control key will deselect the row. Likewise, interpreting the shift key on row selections will allow multiple selections with one mouse click instead of forcing single clicks on each check box row. I know this is not how thinwire does selections, but my user base is used to doing selections the "standard" way - every row that is highlighted is assumed to be selected. However, with thinwire, you can have the situation where a gridbox displayed with check boxes can have several check boxes checked and still have a row selected without having it's corresponding check box set. Is the user's intent to include the non-checked row as part of the selection?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is feature request for such behavior exists somewhere in the FR list, but I should admit, that standard MS behavior for multi-selection is not very convenient, as it is to easy to lose selections when they do not fit single page. Current checkbox-based style seems to be much more robust. And sure, if checkbox are used any row without checked checkbox is not part of the selection (regardless is it highlited or not)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah... I'm somewhat mixed in my opinion of how multi-select should work. For most cases I agree with Oleksandr and I think that checkbox multi-select is better and preferable. However, many users are used to the MS way of multi-select. One solution might be to have some form of the shift/control key modifiers work in combination with the checkboxes (i.e. holding shift will check/uncheck a range, holding control will toggle a row). In any case, I wanted to add that if you set the 'fullRowCheckBox' property to 'true', then the row will toggle it's checked state wherever you click on a row, not just when clicking on the checkbox.
-Josh <G>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess that (multi)selected rows and checked (via checkboxes) rows shall be kept completely independent and both features should be provided (and each of them activated/deactivated independently via API).
Regards,
Oleksandr
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My problem with the multi-select check box design is that it requires a click for each row (no multi-selections with a single key stroke), and no way to conveniently deselect all rows. I have resorted to adding menu items in the menubar to handle these cases (i.e., a Select All and Deselect All option). Adding the fullRowCheckBox capability so that the check box is automatically checked is not practical because some actions require only a single row selection - the user would have to go back and remove selections before the action could be performed. I would like the gridbox to behave like the following two examples:
Yes they show standard MS-style selection, which is very ugly indeed (one false click and all selections are lost). This is one of the main reasons why I never use Windows Explorer for multi-file operations :).
Current selection style in ThinWire is not perfect as well. Probably, something like to file-selection behavior of FAR or Total Commander may be implemented.
Regards,
Oleksandr
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How do I prevent GridBox from always selecting a row in the GridBox?
When you add rows to a GridBox it always selects the first row. How do I prevent this happening?
This is a major issue for me as I am displaying a paged GridBox and the entry the user has selected is may be on one a page that he is not currently displaying....
Thanks
Richard
I guess it depends upon what you are trying to acheive but it doesn't look like it is possible to not have anything selected in a gridbox at this time.
To get around this you could:
Have the data loading when you display the page that is currently not displaying.
Have a button instead of listening for action/property events in the gridbox.
Use the gridbox checkbox funtionality in conjunction with the action/property event.
Create a custom compound component(from labels etc) to do that functionality.
Alter your thinwire source to provide this functionality in the existing gridbox component.
Hi
You could 'cheat' the system by changing the styling for highlight on the GridBox to be the same as for all other lines, thus none would appear to be highlighted to start with, and then use checkboxes...
I thought I had asked in this forum whether an option might be added to GridBox to make the checkboxes behave like radio buttons - ie so only one at a time can be selected, but I can see now that I could get something similar by using the trick above to apparently deselect everything and then use a click listener to change the highlighing style back to something else once the user has clicked on a line in the Gridbox - Hmm, I'll have to go try that out, see if it's possible! (I'll have to use my own flag to ensure that the user has selected something rather than getting the GridBox default by accident as it were...)
You could also exploit a new feature (or bug??) in the latest build by adding an additional row and then immediately removing it which will cause row highlighting to disappear.
Just a quick chime in on this. I've been watching this discussion off and on and I just got a free moment to express a few thoughts on this. First, and this may seem odd, but ThinWire intentionally prevents the deselection of all rows in a GridBox. This is not a bug or a failure to implement the feature. As you can imagine, such a thing would be relatively easy to implement. In fact, we went out of our way to prevent such behavior for a couple reasons.
The first reason actually falls back on UI design principles, specifically the idea that you should never let the user do something that they can't undo. So, if a dropdown has absolutely no selection to start with and a user makes a selection, they should be able to unselect it. Since there's no clear way (that a user would figure out) to do that, it's always best to pre-select a default or add an empty option to the drop-down. Thus, ThinWire implements the principal that a populated drop-down must have an option selected.
The second reason is more for the benefit of the developer and falls back on API design, specifically the tenet that you should avoid returning 'null' if at all possible. ThinWire tries to adhere to that tenet as much as possible, so you'll notice that there are very few cases in the API where you can actually get a null from a method call. All strings always return empty strings and most inner objects are pre-initialized or initialized on demand, to prevent you from having to do null checking. The same concept carries over to drop-downs. Do you want to have to do this everytime you work with a dropdown?
GridBox.Row row = dd.getComponent().getSelectedRow();
if (row != null && row.isChecked() != null) {
//... do something useful with the row
}
Or does this make life easier:
GridBox.Row row = dd.getComponent().getSelectedRow();
if (row.isChecked()) {
//... do something useful with the row
}
Sure, it's minor... but if you do lots of gridbox operations, those null checks can really pile up. What does everyone think?
-Josh <G>
1) You have to check for null already now for gridbox.getSelectedRow() if you dynamicly fill the gridbox and it is possible that it is empty.
2) What about keeping the current behavior as default and add an additional method "forceUnselectAll()" (or something like that) and delegate the responsibility for checking null to the api-user after doing such a "hard" unselect.
3) A general switch "setAutoSelectRow(true/false)" would be much more convient for api-users but may be not so easy for the api-developers because the switch must be considered every time autoSelection is done now (adding the first row, deleting the selected row, may be more?). Defaults to true to preserve current behaviour.
I really dislike current behavior which seems to me absolutely unnatural. If it like going to shop and to be forced to by something :) And deselecting a row in UI may be done in very natural and intuitive way - just click selected row once more. Add additional check for null does not bother me at all. There is nothing weird about nulls and if something naturally may be null let it be. Anyway better then ugly substitutes/
Regards,
Oleksandr
If this topic is expanding to the general behavior of the gridbox, then the standard (Microsoft) behavior is to add control and shift key interpretations to the mouse clicks when selecting/deselecting rows. If a row is selected, using the control key will deselect the row. Likewise, interpreting the shift key on row selections will allow multiple selections with one mouse click instead of forcing single clicks on each check box row. I know this is not how thinwire does selections, but my user base is used to doing selections the "standard" way - every row that is highlighted is assumed to be selected. However, with thinwire, you can have the situation where a gridbox displayed with check boxes can have several check boxes checked and still have a row selected without having it's corresponding check box set. Is the user's intent to include the non-checked row as part of the selection?
There is feature request for such behavior exists somewhere in the FR list, but I should admit, that standard MS behavior for multi-selection is not very convenient, as it is to easy to lose selections when they do not fit single page. Current checkbox-based style seems to be much more robust. And sure, if checkbox are used any row without checked checkbox is not part of the selection (regardless is it highlited or not)
Yeah... I'm somewhat mixed in my opinion of how multi-select should work. For most cases I agree with Oleksandr and I think that checkbox multi-select is better and preferable. However, many users are used to the MS way of multi-select. One solution might be to have some form of the shift/control key modifiers work in combination with the checkboxes (i.e. holding shift will check/uncheck a range, holding control will toggle a row). In any case, I wanted to add that if you set the 'fullRowCheckBox' property to 'true', then the row will toggle it's checked state wherever you click on a row, not just when clicking on the checkbox.
-Josh <G>
I guess that (multi)selected rows and checked (via checkboxes) rows shall be kept completely independent and both features should be provided (and each of them activated/deactivated independently via API).
Regards,
Oleksandr
My problem with the multi-select check box design is that it requires a click for each row (no multi-selections with a single key stroke), and no way to conveniently deselect all rows. I have resorted to adding menu items in the menubar to handle these cases (i.e., a Select All and Deselect All option). Adding the fullRowCheckBox capability so that the check box is automatically checked is not practical because some actions require only a single row selection - the user would have to go back and remove selections before the action could be performed. I would like the gridbox to behave like the following two examples:
http://demo.qooxdoo.org/current/showcase/#ListView
http://demo.qooxdoo.org/current/showcase/#Table
The table example even allows the dynamically reordering of the columns by dragging a column to a new location!!
Yes they show standard MS-style selection, which is very ugly indeed (one false click and all selections are lost). This is one of the main reasons why I never use Windows Explorer for multi-file operations :).
Current selection style in ThinWire is not perfect as well. Probably, something like to file-selection behavior of FAR or Total Commander may be implemented.
Regards,
Oleksandr