Grid with custom table

wxPython Users
1

Hello,

I'm trying to use a custom table to add GridCellEditors in each cell of the grid.
I first check GridCustTable.py from wxPython demos and everything seems to be perfect until I replace the 18th line

gridlib.GRID_VALUE_NUMBER + ':1,5',

by

gridlib.GRID_VALUE_NUMBER + ':1,1',

So instead of getting a SpinCtrl in the corresponding column (with 1 as the only allowed value), I get a standard TextCtrl which allows all numbers!

Is this a correct behavior?
Do I have to set my own GridCellEditor ?

What is also strange is that I test the GridCellEditor against all known GridCellEditor and I always get False:
isinstance(self.GetCellEditor(event.GetRow(), event.GetCol()), wx.grid.GridCellXXXEditor) # one test per editor

Thanks for your previous and future help.
Mathias

2

Mathias Lorente wrote:

Hello,

I'm trying to use a custom table to add GridCellEditors in each cell of the grid.
I first check GridCustTable.py from wxPython demos and everything seems to be perfect until I replace the 18th line

gridlib.GRID_VALUE_NUMBER + ':1,5',

by

gridlib.GRID_VALUE_NUMBER + ':1,1',

So instead of getting a SpinCtrl in the corresponding column (with 1 as the only allowed value), I get a standard TextCtrl which allows all numbers!

Is this a correct behavior?

Sort of. The number editor decides whether to use a spinctrl based on if there is a range of values given, and it checks that by testing if min == max or not. So, yes it is behaving correctly based on how the code is written, but I agree that maybe it should be a little smarter about it. Please enter a ticket about this at trac.wxwidgets.org.

Do I have to set my own GridCellEditor ?

Yes, if you want to still use the spin ctrl when there is no range of values.

What is also strange is that I test the GridCellEditor against all known GridCellEditor and I always get False:
isinstance(self.GetCellEditor(event.GetRow(), event.GetCol()), wx.grid.GridCellXXXEditor) # one test per editor

Look at the return type of GetCellEditor. The editor, renderer, and attr classes do not derive from the right C++ class and so they have not had the magic applied to them that allows the Python wrappers to return either the original Python proxy object, or at least an instance of the proxy class that is the right type. So it is falling back on the default SWIG behavior of just creating a new proxy object of the type of the return value from the C++ method, which in this case is the base class GridCellEditor.

ยทยทยท

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!