Can you set multiple wxGrid Column Attributes?

[Petr Smilauer]

Bob,
 thank you - this is much more clearer now: you set
individual cell background colour and then you re-set
whole column background. The individually coloured
cell keeps its original colour.

 Right, here we are: this behaviour is not a bug, this is "by design".
I know you do not have time to digg into wxWidgets sources, 
but if you find your way into  wxGridCellAttrProvider::GetAttr 
method (in wxWidgets grid.cpp), you will find that for cells to 
which both cell and column (and/or row) attributes apply, 
attribute provider does merging of these attributes. And individual 
cell attribute has a priority over columns, and both have priority over rows.

 Cell attribute provider class (which is created automatically by the
wxGridTableBase class, which you use implicitly, in the form
of wxGridStringTable - a class derived from it, by calling CreateGrid
method in your code) simply records attributes for individual
cells, for columns, and for rows. There is no way to remove already
set attributes - only replace them by another value (but then, you
would have to re-set your cell 0,0 - not whole column) or replace
whole attribute provider object by a new one.
 
 Or you can, I am sorry to say so, write your own attribute provider 
class. Alas, you must start from the ground up, as the default class
implementation details are declared private, not protected. But
if you have a simple, deterministic grid, in which you conditionally
colour cells at particular coordinates (i.e. meaning of cols and/or
rows is application-specific), it shall not be so difficult to write it,
I guess.

Best regards from  Petr Smilauer
Ceske Budejovice

----- Original Message ----- 
From: "Bob" <wxwidgets at gmail.com>
To: <wx-users at lists.wxwidgets.org>
Sent: Sunday, January 13, 2008 4:29 AM
Subject: Re: Can you set multiple wxGrid Colum Attributes?


> On 1/11/08, Petr Smilauer <petrsm at jcu.cz> wrote:
> 
>>>> Right, so you are doing both operations at the same time.
>>>> What does your "color problem" mean?
>>> That the above code is not restoring the grid to the default
>>> background color.
>>Perhaps a little more detail would help. Restoring from what
>>state? You set a different attribute for these columns before?
>>using SetColAttr call too, with the same column indices, but
>>different Attr object?
> 
> I set the grid cell to a different color from the default color,
> which works fine:
> 
> wxColour color_red = wxTheColourDatabase->Find("RED");
> m_grid->SetCellBackgroundColour( 0, 0, color_red );
> 
> What doesn't seem to work is changing
> the background attribute of the entire column back to
> the background color. This was with Windows XP,
> using the Digital Mars compiler and wx287. I just
> tried the code on my home system, Linux, with both
> wx287 and wx263, the background color does not change.
> 
> I put together a small project with DialogBlocks that
> shows the problem if you want to try it.
> http://www.unusualresearch.com/GridProblem.zip
> 
> It draws a grid coloring one of the cell backgrounds red,
> then I expectedthe following code to change the red background
> back to the default system 'white' background,
> when I pressed the button:
> 
> 
> /*!
> * wxEVT_COMMAND_BUTTON_CLICKED event handler for ID_BUTTON1
> */
> void Grid::OnButton1Click( wxCommandEvent& event )
> {
> wxColor default_cell_background = m_grid->GetDefaultCellBackgroundColour();
> 
> wxGridCellAttr *attr = new wxGridCellAttr;// Remove all previous background
> colors
> attr->SetBackgroundColour( default_cell_background );
> 
> m_grid->ClearGrid();
> m_grid->SetColAttr( 0, attr );
> 
> m_grid->SetCellValue( 0, 1, wxT("<- Color Change?") );
> 
> m_grid->AutoSizeColumns();
> m_grid->Fit();
> }
> 
> The color remains red after pressing the button, but the other
> grid changes did happen, like the message showing up in cell (0,1),
> and the grid being resized.
> 
> Am I doing something wrong in the above code, or is the
> problem in wxWidgets?
> 
>>> The idea of using any framework is to save development time,
>>> not use it up. The boss expects this project to ship in his
>>> life time, which may exceed mine if it doesn't work. ;-)
>>If demands of your boss prevent to set a breapoint at your code
>>to fix problems, it is probably time you change job.
> 
> I agree completely. I'm 90 miles north of Pittsburgh, PA,
> with extensive background in embedded systems design,
> if anyone wants a resume.
>