wxGrid Manual
Well, I always find it's helpful to have a concrete idea of what something looks like before I start talking about it. Here's a screenshot of a wxGrid in action:
The grid here uses custom renderers (the clock and the colour swatch), and shows both a selection (the dark-blue range of cells in the upper-right) and a cursor (the blue box around a cell in the lower-right).
Although the normal use of a wxGrid is to access data which is in tabular formats, the wxGrid provides mechanisms for mediating between your application-specific storage/representation and the grid's tabular format. The grid shown above is part of a property-editing framework (wxprop) which uses a wxPyGridTableBase to map object properties into a columnar format for access by the grid. Even for applications where your data is already in tabular format, these abstraction mechanisms allow you to intercept and customise data access.
The wxGrid system has the following basic structure:
wxGrid (wxWindows window)
DataTypeRegistry (implicit, doesn't exist as it's own object)
wxPyGridCellRenderer (plug-in value renderers)
wxPyGridCellEditor (plug-in value editors)
wxPyGridTableBase (data management) Drawing/representation of the grid (handled directly by wxGrid) Edit-cycle management (handled directly by wxGrid) Selection management (handled directly by wxGrid) Cursor/focus management (handled directly by wxGrid)
Event generation (handled directly by wxGrid)
The Major Grid Classes
- The scrolled window subclass which mediates the interface between the generic wxPython environment and the grid-specific environment.This is the "concrete implementation" of the grid. It handles rendering the column and row headers, the gridlines, scroll bars, column-resizing controls, selection management, etc. The various parameters affecting this functionality are set through the grid class (whether headers can be resized, wether cells are automatically resized to fit content, etc.) The grid provides mechanisms for registering particular viewing and/or editing classes (see below) for use with particular data types.
The grid makes calls to the wxPyGridTableBase to determine what data type is present in any given cell, to access the data within any given cell, and generally to interact with the application-specific storage of the grid's data. The grid's data type registry is used to instantiate and interact with cell editors and cell renderers. The grid interacts with these objects through their published APIs/interfaces.
- Interface between the wxGrid and your application-specific data sources. Override methods in this class to determine how the grid will access your data. The table also provides information regarding the data type, empty and editable status of any given cell.
A utility class which manages the in-cell editing control used to change values for a particular cell. You should note that there is a single wxPyGridCellEditor for any given data type registered with the grid, and it is reused for all cells of that type.
- A utility class used for customizing the representation of a data type within the grid's cells which are not being edited. This class is also responsible for determining the "best size" for the cell when automatic column or row sizing is enabled for the grid.
Provides a mechanism for altering the display of particular rows, columns, or individual cells within a grid. Preferably calculated and returned by your wxPyGridTableBase's GetAttr method, alternately stored in wxGrid's (in-memory) storage.
- A number of event classes providing information about user interactions, and editor life cycles. These are all generated as coming from the wxGrid window, and can be mapped for that window.