This has been giving me a real headache to find the cause.

When setting multiselect to true I notice a significant latency when changing cells. On my system, changing rows with up/down arrow without letting the Grid scroll is using up 20% of my CPU and it may take up to a second to see the selection change. I'm working on a virtual Windows 2012 RDS Server.

When setting multiselect to false the CPU-usage goes down to about 5% and the selection is changed immediatly doing the same thing.

It seems it gets worse the more rows and icons I have in the grid.

I've verified this behavior in a new .accdb (Access 2010) filling a grid with random data with checkboxes, cellbackcolor and icons. No events, just Multiselect set to true.

Is it just me experiencing this? Im using iGrid v6.00.0020.

Regards

Henrik

I have just rechecked the source code. Even if multiselect mode is on, the current cell selection must be changed fast. You may experience a little delay if your grid has 10'000+ rows and almost all of them are selected before you change the current cell (as the selection must be removed from all rows), but this operation should work very fast if you have the only selected cell.

Can you prepare and send us a sample to reproduce this odd behavior?

  Multiselect.zip (67kb) downloaded 84 time(s).

Absolutely, here you go. Let me know if you have any problem running this.

I can also confirm I'm having the same issue on my Surface 4 Pro with Win 10. Not as bad since it got a bit more power - but noticably.

I analyzed the corresponding code execution paths under the VB6 debugger to understand why this odd effect may happen in MS Access. The only problem part of code related to this issue is that iGrid redraws all the cells in the viewport when the selection is changed in multi-select mode. As I remember, we changed this behavior in one of the latest releases (6.0.20) to avoid the so-called tearing effect at redrawing when the user selects several cells. And this issue became noticeable for you as you have a lot of cell with images (drawing images require more CPU resources).

Ok, let me play with this thing more. Perhaps, I'll be able to optimize it. Meanwhile, you can try earlier versions of iGrid, earlier than 6.0.20, to check whether this problem is present in them.

I've tested with 6.0.0 and it does not have this problem. The change you mentioned about the tearing-issue sounds like a probable culprit.

Many of my users are extra vunerable to extra graphical updates because of windows 2012 rds servers poor graphical handling in remote desktop. It has gotten better since 2003 though.

Also, each of our servers host about 20-25 concurrent users which makes a light weight control vital for us. You can imagine what happens when each user use 20% of the CPU.

I've disabled multiselect for now until there is a solution.

/Henrik

I attached a screenshot of a typical grid in my app. It has 26 rows and 10 columns.

Using the down arrow to move from the first row to the last row takes roughly 5 seconds with multiselect turned on, and 1 second with multiselect turned off. The difference is huge.

I don't think there's unusually many images in the grid.

I've recieved a new build from Igor (6.0.26) where this has been fixed.

Thanks, and good job Igor!