Anyone remember why a 7.5.3 <DataGrid>.Selection.SelectAll only selects the visible rows and not those rows hidden below the scroll?

For example, a bound datagrid has a recordset with 10 rows.
The physical datagrid (due to its positioning on within the container) is only able to present, say, 7 rows to the user and in order to see rows 8 through 10 you would need to use the scroll.

If you select multiple rows using shift or ctrl clicks or if you do a selection.selectall, only those that are visible are selected, so that a .selection.count will never = recordset.recordcount. It will only ever equal the client-visible rowcount. All rows exist in the dataset and can be referenced to within a VS10 debugging session so in effect, whilst recordset.recordcount = 10, .selection.count = 7.

If you grab the tob of the form (it is a DG on a tab) and drag it up the screen so that you can see all rows without needing to use the scroll, all is OK.

Before it is suggested, "Sorted" cannot be True in this instance as utilising DataGridCustomdrawCell causes an CTL_E_OUTOFSTACKSPACE exception as was always the case with this.

I have seen a resolution / work-around for this a while back but it alludes me.

I may need to end up ripping out this incumbent customisation and port it to a .NET extension with a reliable datagrid if I can not get to the bottom of it soon.
No worries, just thought someone might remember. 

Dave

The problem is indeed that SalesLogix is trying not to load the whole Recordset, think about the different properties on a Recordset (local vs server side, etc)

The way to force it to load the whole Recordset is to set the Sortable property of the Grid to true, that forces SalesLogix to have to preload the whole grid.

The description for the Grid Sortable Property reads as follows:

Determine whether the grid's sorting and grouping capabilities are enabled. If set to true, the whole dataset will be loaded to memory.

That said, if you are getting the Error you agre getting is because your Dataset is probably quite large and consumes a lot of memory.

Maybe you can provide your own "Select All" option on the right click menu (or a button), and then you can track the Selection status on your own (mostly to catch the SelectAll). If the user clicks on a node, and had previous selected all, then you set your own variable as not selected all.

Also, maybe you need to reconsider what is being done on the CustomDrawCell event (is it a calculation item, or a drawing item)?

Maybe you can have a hidding grid used for row selection (with the sortable property turned on, and somehow flip the grids as needed (something like having the user have to click on a button prior to make a selection, which would allow you to flip the grids), once they have acted on that selection, flip them back)

Again, it seems like you know the answer to your main question: how to load the whole Recordset locally (set Sort = true), but that doesn't work well with your CustomDrawCell code.

Another alternative may be to visit that code and try to reduce what is being done there to see if that helps out.

Hi Raul,

The dataset wouldnt warrant VSS anyway (with the issues that it brings to the party) also I cant have sortable = true due to the inherant defect on the control which causes the CTL_E_OUTOFSTACKSPACE exception to be thrown when the other control combinations I have (coupled with the custom cell painting on DataGridCustomdrawCell) happens.

Not to worry, I have got around this by simply knowing that the fact that when we want to do a select "All" means simply that - ALL>
I can pass the grid recordset out and process the recordset itself rather than cycle through the .SelectedNodes.Item(<selectedrow>.Values(<columnindex> collection.

I was going to go down the rs passing before, I just thought that I had seen a resolution for this before. 

All sorted now via this workaround and only handful of lines of code added.
The joys of mainting other's code  

Thanks anyway

Dave

You have to (i.e. MUST) choose Sorted = True. (or go to another grid control).

One workaround for the speed issue is to always retrieve the data directly from the SQL Server database.......8 times speed improvement. We used to bomb out on recordsets of 1,000+ rows......using direct SQL we can routinely retrieve 10,000+ recordsets in grids, color them (it only colors what you can see!), and my former boss came up with a way to Trap Columnar sorts and use a recordset sort intead of going after the server side data again and again.....