Hi Igor,
hi everybody,

I use iGrid as an ActiveX control in Access 2010.

The iGrid is going to be redrawn each time I open the option list of a combobox cell and also when I chose a item of the list.
For the user, this flicker is quite an annoying behaviour; furthermore, the redraw of a complex iGrid can take a considerable amount of time and interrupts the user's workflow.

I've found the same behaviour, if I want to change a picture of an image control withing the same form as the iGrid is (e.g. using the AfterCommitEdit event).
Even though iGrid doesn't loose the focus, it performs a complete redraw. As a result, the screen also flickers.

So my question is: How can I prevent iGrid to be redrawn (or more precisely: to prevent flickering) ...
... each time I select a combobox on it or choose a list item of the combobox?
... each time I change the picture of an image control outside the iGrid but on the same form?

Here is a link to my test database and a video which shows you more precisely what I mean :)
https://dl.dropboxuserco...3_iGrid%20Flickering.zip 

Thanks a lot for your help!
Regards,
Marc  Test_RedrawGrid.zip (35kb) downloaded 129 time(s).

MS Access has its own, very specific, form package. If you place non-intrinsic controls like our iGrid ActiveX on its forms, the MS Access form infrastructure may cause extra unneeded redrawing if something is changed on the form. This is the reason of the redrawing problem for both cases you mentioned.

We do not have this problem in other development environments like Visual Basic 5/6 which provide us with normal forms based directly on native Windows API forms. As we know, this issue hasn't been also revealed in UserForms in MS Word/Excel VBA. But MS Access is a very special case, and unfortunately, we can do nothing with that as it is beyond of our sphere of influence.

The only thing which may help the developers to improve the situation with drawing performance is to provide the users with the compiled version of the database (mde/accde).

MS Access has its own, very specific, form package. If you place non-intrinsic controls like our iGrid ActiveX on its forms, the MS Access form infrastructure may cause extra unneeded redrawing if something is changed on the form. This is the reason of the redrawing problem for both cases you mentioned.

We do not have this problem in other development environments like Visual Basic 5/6 which provide us with normal forms based directly on native Windows API forms. As we know, this issue hasn't been also revealed in UserForms in MS Word/Excel VBA. But MS Access is a very special case, and unfortunately, we can do nothing with that as it is beyond of our sphere of influence.

The only thing which may help the developers to improve the situation with drawing performance is to provide the users with the compiled version of the database (mde/accde).

Hi,
thanks a lot for your quick response.
Indeed, the drawing of iGrid in a compiled database ist faster. But there is still a flickering and input workflow is going to be lagged if it is a large iGrid.

Although I must admit that Access (and its forms) has its own logic in many cases I do not agree with you that an ActiveX is forced to do a redraw/refresh. (see video attachement)
And I do not understand why it is an Access forms issue if iGrid redraws itself when I open/close the list of a combobox cell within iGrid.

Please find attached a short video that demonstrates an Image Viewer CP Pro ActiveX Control from Viscom Software. As you can see, it doesn't redraw while iGrid does.

It would be great if we could prevent iGrid from initiating a redraw each time we access a combobox cell!

Regards,
Marc

It would be great if we could prevent iGrid from initiating a redraw each time we access a combobox cell!

These are the nature of combo box cells and the basics of form interaction in Windows. If you open the drop-down list, another popup window covers the main grid window. When the drop-down list is closed, the iGrid window should be updated (redrawn) as it was covered by another window.

We cannot prevent the grid redraw in this case at all, but the question is why does this work so bad in MS Access when we have no problems with the same code in other development environments??

Please find attached a short video that demonstrates an Image Viewer CP Pro ActiveX Control from Viscom Software. As you can see, it doesn't redraw while iGrid does.

The comparison is not correct. A grid is a much more complex control if we talk about its visible part, it is not just a rectangle that displays a static image (though the Image Viewer control can be sophisticated in other parts, such as internal image processing algorithms).

It would be great if we could prevent iGrid from initiating a redraw each time we access a combobox cell!

These are the nature of combo box cells and the basics of form interaction in Windows. If you open the drop-down list, another popup window covers the main grid window. When the drop-down list is closed, the iGrid window should be updated (redrawn) as it was covered by another window.

We cannot prevent the grid redraw in this case at all, but the question is why does this work so bad in MS Access when we have no problems with the same code in other development environments??

Please find attached a short video that demonstrates an Image Viewer CP Pro ActiveX Control from Viscom Software. As you can see, it doesn't redraw while iGrid does.

The comparison is not correct. A grid is a much more complex control if we talk about its visible part, it is not just a rectangle that displays a static image (though the Image Viewer control can be sophisticated in other parts, such as internal image processing algorithms).

Hi Igor,
thanks for your reply. The status is as follows:

• [SOLVED] the redraw of the grid when a picture outside the grid is changed. It actually works if an additional iGrid is used as "image control" (i.e. CellIcon method) to display the picture (and not the standard picture control)

• [OPEN] redraw of the WHOLE grid when a ComboBox Control within a cell is either opened and/or a new item selected.

You wrote that you cannot do anything about the redrawing of the whole grid, when a ComboBox is selected and that this would be some aspect specific to Access.
However I would like you to have a second look into that topic:

If you open a ComboBox the Event-Handlers for Before/AfterCellContentsDraw are called for EVERY VISIBLE CELL within the grid. This behavior is not triggered by Access.
Example: Let’s consider a grid with 50 rows and 15 columns. Column 1 would be the cell with a ComboBox. If you then clicked on Cell(row=48, col=1) and opened the ComboBox ALL 50 ROWS were redrawn.
However all the redraws for row 1..47 are unnecessary. In the exemplary setup this would mean that there are at least 47 * 15 = 705 avoidable cell redraws!
The same happens, after an item from the dropdown list is selected.

In the case of a ‘normal’ cell selection change only the row(s) of the cell that lost and the one that got the focus are redrawn.
(even though also in that case all cells within the affected row(s) are redrawn and not just the cell that lost / got the focus)

I think the ‘flickering’ in the ComboBox selection case might have something to do with the described update behavior.
Access as an environment might be sub-ideal too, but if only the rows needing an update would be redrawn the effect on the user would be far less dramatic.

It would be great if you could offer a solution on that, because the effect is really bad on big grids (which we unfortunately need a lot).

Nobody knows the redraw behavior of the grid better than you, but for testing convenience you find a database attached to that post.
The database outputs the row and line of the AfterCellContentsDraw-Event in the Debug-Window. Just change selection or click on the

Thanks,
Marc

[OPEN] redraw of the WHOLE grid when a ComboBox Control within a cell is either opened and/or a new item selected.

Marc, I totally understand what you are talking about. Unfortunately (for this particular case), iGrid is implemented in VB6 using its native "framework" for ActiveX component creation. In our case, this means that the UserControl_Paint event which causes the redrawing of the whole grid is raised when the drop-down list is closed (an equivalent of the OS WM_PAINT message which is sent to a window when its contents should be updated). In this event/VB-framework we are provided with no information what rectangle of the whole control window requires real updating.

But even if we had this rectangle's coordinates, this would not help us a lot. In MS Access, a very specific and non-traditional sequence of Windows messages is used when our controls are hosted in its forms. Perhaps, it sends an extra WM_ERASEBKGND message which also causes the whole control update or something like that. These things do not happen in other development environments, and we cannot "jump over" it. I touched this problem several years ago, when rewriting our internal procedures to process keystrokes specially for the MS Access case.

I admit that this all can sound strange for those who never used real WinAPI, but we rely on Windows messages and other "rules of game" our host container should adhere. If something goes wrong in our host platform, we also have problems in the hosted controls. The same infrastructure works well in VB6 and other development environments, so I would not classify it as a bug of our ActiveX grid.

In any case, I've noted this issue in my internal to-do list for iGrid. If I find some useful bits of information which could help us to enhance it, I will definitely give it a try.

Thanks for your investigations and your answer.

Hello Igor/10Tec

Just to let you know, reducing the flicker would be interesting and valuable for us, too.

Regards,
Oliver

After working hard on the problem, we still cannot overcome this flickering problem if we open an iGrid drop-down list in MS Access. We use the native Windows combo box lists functionality for the iGrid combo lists, and MS Access clears the grid contents every time when we open a combo list. The attached pictures demonstrate what's happening if we do not redraw the grid contents after the list has been opened. Intercepting such system messages as WM_ERASEBKGND does not help in this development environment. It seems, MS Access does something very special we cannot affect or change anyhow.

We would be very glad to know any ideas of how this problem could be solved, so feel free to share your thoughts with the community on this forum or send us a letter to our support service at any time.

We redesigned the internal infrastructure related to drop-down lists in iGrid ActiveX v6 and eliminated this flickering problem in it.