Spread 8.0 Documentation
Creating Custom Cells
Support Options
User's Guide > Setting Up the Control > Setting the Cell Type > Creating Custom Cells

Glossary Item Box

Creating Custom Cells


Overview

Custom cells can be created in addition to the existing cell types. There are custom cell events (or callback functions) that can be used to display the cell and create an editor control. The CTSample project in the samples folder (under the main Spread folder), shows a rich text custom cell as well as a check box cell and a text cell.

Use the AddCustomCellType method (or function) to create a new custom cell type for use in cells. This method specifies the name of the custom cell type, whether the cell type will support editing, how it will support cell overflow, and whether it will use a renderer control to paint the cells. If the custom cell is editable then use code in the CTCreateEditorControl event (or callback function). If the cell can overflow into adjacent cells use the CTGetPreferredSize event (or callback function) to determine the overflow. If the cell will use a renderer control to draw the content, use the CTCreateRendererControl event (or callback function).

If the cell type uses a simple window control for the editor or renderer and the custom cell name is identical to the window class name registered for that control, then the Spread control will create instances of the control for you for editing and rendering. In this case, the style value set in the TypeCustomStyle method will be used for the window styles for the control that Spread creates. The window class must already be registered with RegisterClass in order for Spread to be able to create it. Otherwise you must implement code in the CTCreateEditorControl and/or CTCreateRendererControl event (or callback function) to create and return a control instance to use (in this case Spread does not use TypeCustomStyle). The editor control should be a different instance than the renderer control unless the cell type will only be used in one cell; otherwise, there may be issues when two cells using the same cell type try to use the same instance of the control for editing and rendering.

If the cell type uses a renderer control and the renderer control supports drawing to a device with WM_PRINT, then Spread will handle the rendering for you; otherwise, you must implement code in the CTPaintCell event (or callback function) to do the drawing.

If the cell type is editing simple text values and the editor or renderer control supports the standard WM_GETTEXT and WM_SETTEXT messages, then the Spread control will handle getting and setting values to and from the editor or renderer control using those messages. If you wish to have the cell handle non-string values or if the editor or renderer needs to get or set the value by some other means than WM_GETTEXT and WM_SETTEXT, then you would need to implement code in the CTGetEditorValue and CTSetValue events (or callback functions) to handle getting values to and from the editor and renderer controls.

When a custom celltype creates an editor or renderer control and the control id is stored in the celltype structure, a reference is added to the custom celltype. In order to remove a custom cell that is created this way, all references to the custom cell's editor and renderer controls must be removed.

Copyright © GrapeCity, inc. All rights reserved.