Forum

Dear Support,

I have a grid, each time the mouse moves, I need to redraw one cell in the grid.
I could not find a method to update only part of the grid - something like
RedrawCell(int nRow, inrt nCol) or RedrawRow(int nRow) etc.
Please point me to the right direction.
This is essential to me, as I suffer from a great performance loss due to this...
Thanks,
Ron.

Dear Support,

This is not a big issue, I can write my own utility function for doing this, but I don’t think there are lot of time you want to repaint only the Drop-Down button... usually you want to invalidate a cell or a roe or a column (or several rows and/or columns).

In any case, if you don’t think that helps the community, I will do it in my utility class.

Regards,
Ron.

So every time one row needs to be repainted i need to write all these lines of code?

What the user may need to repaint when the user knows cell’s row/column indices:

1) The entire cell only.
2) Some part of the grid cell or a combination of its parts:
a) Check box or radio button.
b) Text label.
c) One or several built-in buttons:
c1) Up only.
c2) Down only.
c3) Up-down.
c4) Drop-down.
c5) Ellipsis.
d) Icon area.
e) The rest, which is an internal area free of any other built in-parts. It appears between the built-in cell parts aligned on left and on right. The slider/scroll-bar grid cell uses the rest area as a place for a slider or a scroll-bar like looking control emulation which works as a built-in part of this cell type.
f) Specific built-in parts of header cells:
f1) Focus arrow.
f2) Sort arrow.
g) Any specific parts of any particular grid cell classes. For instant, parts of scroll-bar like area in slider/scroll-bar grid cell.
h) Each column reserves some extra space on left and/or right. Each row supports some extra space at top and/or bottom. So an inner data cell may reserve some free space area around it and this space can be used for displaying some additional information. For instance, each data row in the report grid window reserves extra space at the bottom of the row for painting auto-preview data related to each data row.
3) Entire row of cells. In Prof-UIS 2.82 each row can contain outer maximum 3 parts (a, b, c) and in Prof-UIS 2.83 row can contain 5 parts (a, b, c, d, e):
a) Inner data cells.
b) Outer header cells at left.
c) Outer header cells at right.
d) Frozen inner data cells at left. New in Prof-UIS 2.83.
e) Frozen inner data cells at right. New in Prof-UIS 2.83.
The user may need to repaint any combination of these row parts.
4) Entire column of cells. Same as 3 but in vertical direction. Prof-UIS 2.83 also supports frozen cell areas at top and/or bottom inside inner area of data cells.
5) Outer header cells at top-left, top-right, bottom-left, bottom-right.
6) Tree grid also supports outline area in one or more columns. User may need to repaint outline area only for some purpose.
7) Tree grid and report grid are supporting tree like structure in vertical direction. User may need to repaint one row and entire visible children in this row only.
8) We are working on cell join feature which will add more than one item into this list.
9) We are also going to support per-cell colorized borders and corner markers which can be used for accessing some data specific for particular grid cell only (for instance, multiline cell description text displayed in some big tooltip window).
10) It’s possible to override the CExtGridBaseWnd::OnGbwAdjustRects() virtual method and modify computed by default rectangular areas of grid cells and make some grid cells placed over/under other grid cells. This situation brings complete new list of cases and should be discussed separately.

Most of the rectangular parts described above can be computed with single invocation of the CExtGridWnd::GridCellRectsGet() method. Some rectangles can be computed as result of the CExtGridWnd::GridCellRectsGet() method combined with some other rectangles. We are not sure it’s good idea to code one method for all or most of cases described above. This method will have more complex parameters then entire code for repainting we advised you to use. The result of this method can be some complex HRGN instead of CRect. We are also not sure we should create 10 or more standalone methods for particular situations. But we can add any method which is exactly needed in your project.

Yes, you version is correct. It was our typo. We could add such simple re-painting methods but they would not be very useful. In many cases the entire row/column or simply some part of the cell should be repainted.

It’s not very clear to me how this solves the problem - does pRectCellExtra return the whole row?
Maybe you meant:

rcInvalidate.left = rcClient.left;
rcInvalidate.right = rcClient.right;

and not:

rcInvalidate.left = rcClient.left;
rcInvalidate.top = rcClient.top;

Also, how about a wrapper for this in the grid class?

Thanks,
Ron.

You do not need to walk through all the cells in a row if you need to repaint this row only:

CExtGridWnd & wndGrid = . . .
LONG nRowNo = . . . // what we need to repaint
      if( ! wndGrid.IsWindowVisible() )
            return . . . // nothing to repaint
LONG nColCount = wndGrid.ColumnCountGet();
      if( nColCount == 0 )
            return . . . // nothing to repaint
CRect rcInvalidate;
      if( ! wndGrid.GridCellRectsGet( 0, nRowNo, 0, 0, NULL, &rcInvalidate )
            return . . . // nothing to repaint
CRect rcClient;
      wndGrid.GetClientRect( &rcClient );
      rcInvalidate.left = rcClient.left;
      rcInvalidate.top = rcClient.top;
      wndGrid.InvalidateRect( &rcInvalidate );

Dear Support,

This does boost my performance issue.

However, there are times in which I need to invalidate a full row, and with this solution I need to run over all cells, which again, harms the performance.
Also, how about a simple function that returns the cell rectangle without the other 11 RECTs?
For invalidation all one need is the cell’s rectangle, and this can also make the performance improve.

I think that:

GridCellRectGet(
        LONG nColNo,
        LONG nRowNo,
        INT nColType,
        INT nRowType,
        RECT * pRectCell)
and

GridRowRectGet(
        LONG nRowNo,
        INT nColType,
        INT nRowType,
        RECT * pRectCell)
and

GridColRectGet(
        LONG nColNo,
        INT nColType,
        INT nRowType,
        RECT * pRectCell)

Are a welcomed addition to the library...
Thanks,
Ron.

Dear Support,

Don’t you think this should be an integral part of the grid? If I need to update one cell i need to write all these rows?
Can you please add such functions for the next version? I think it’s needed.

In any case I will try it out see how it improves performance...

Thanks,
Ron.

You should get the coordinates of a grid cell first in client coordinates of the grid window:

LONG nColNo = ...
LONG nRowNo = ...
CExtGridWnd & wndGrid = ...
CRect rcInvalidate;
            if( ! wndGrid.GridCellRectsGet( nColNo, nRowNo, 0, 0, NULL, &rcInvalidate ) )
            return ... // cell is outside of the visible cell range

The CExtGridWnd::GridCellRectsGet() method can compute locations of the visible grid cells only displayed in the client area of the grid window.

Then you should invalidate part of the grid window.

      wndGrid.InvalidateRect( &rcInvalidate );

Then you may need to compute and invalidate some other cells in the same grid window and finally you can invoke the following line of code to make the invalidated rectangles updated on the screen:

      wndGrid.UpdateWindow();