This section provides detailed description of all cell types and features that can be chosen in the tree window of the Build Wizard.

In the Build Wizard, you can choose the grid features you want to use in your application(s). The wizard will create a makefile and/or control factory class based on your selection. You can adjust your selections and rebuild the libraries any time.

Some components depend on other components. For example, the CGXComboBox is derived from CGXEditControl and CGXStatic. When you mark Combobox as checked, the cell types Static and Edit will also be linked into the grid library or application.

Another example is clipboard support. If you choose StyleDataExchange, the CGXStyle::Serialize API will also be linked into the grid library or application.

If you wish to understand the details of the component dependencies, open the file buildwiz.ini and search for the m keys.

This section describes the components in the tree window that specify the output for the control factory class. Each of the components below add one or several lines of code in the Control Factory Class.

The list of file names will be written into the makefile for the grid library.

Choose the cell types to be used in your application(s). Entries for all selected cell types will be inserted in the control factory's CreateControl method. You can toggle the state of all components at once by clicking the checkbox of the parent node.

Supply the listbox entries through the choice list separated with a newline character. The representation of the selected choice as cell value depends on the combobox variant you use. You can register custom variants for CGXComboBox and adjust some attributes for the cell type object (e.g for pushbutton to be always visible). See CGXComboBox in the Objective Grid Class Reference for more details.

Supply the checkbox description to be displayed in the cell through the choice list character. By default the cell value is 0, 1, or 2 (as defined by the user attributes below), but you can also adjust how checked, unchecked, and undetermined states shall be represented through the cell value. (In a tri-state checkbox an empty string in the corresponding style's value represents the indeterminate state.)

You can specify the checked/unchecked representation in the style object with the user attributes GX_IDS_UA_CHECKBOX_CHECKED and GX_IDS_UA_CHECKBOX_UNCHECKED. The default setting is “1” for checked and “0” for unchecked. Other values are treated as undetermined.

If you want "T" or "F" to be stored in the grid for a checkbox you can specify this with:

See CGXCheckbox in the Objective Grid Class Reference for details.

Supply the list of selections through the choice list separated with a newline character. The cell value is a zero-based integer that represents the selected choice.

Supply the listbox entries through the choice list separated with a newline character. By default the cell value will be the text of the selected choice. You can register custom variants for CGXComboBoxWnd and adjust some attributes for the cell type object (e.g zero-based index as value). See CGXComboBoxWnd in the Objective Grid Class Reference for more details.

Supply the listbox entries through the choice list separated with a newline character. Separate the value for each column with a tab character (\t). The cell value will be the text of the key column for the selected choice. See CGXTabbedComboBoxWnd for user attributes that specify the appearance and behavior of the dropdown list.

By default, the cell value contains the date string. If you need to write international applications check the m_bDateValueAsNumber member attribute of the CGXDateTimeCtrl class. This will force the date to be represented as number in the cell value.

Use user attributes to customize the behavior of individual date time cells.

Changing the Spinner Speed on the CGXDateTimeCtrl—Two public members of CGXDateTimeCtrl manage how often a value is incremented as you click and hold down the spinner. m_nInitialTimer is the time (in milliseconds) that the button needs to be depressed before the first increment. Thereafter, m_nNormalTimer is the time (in milliseconds) between increments. The default value of m_nInitialTimer is 500 msecs and the default value of m_nNormalTimer is 100 msecs. For example, to change the incrementing speed once the increment begins, use code such as:

after the baseclass call to OnInitialUpdate() or Initialize().

This section discusses various approaches for joining neighboring cells.

Data Exchange functionality is necessary for doing clipboard operations, OLE drag and drop and reading and writing text files.

Drawing related features that are implemented through abstract base classes. Concrete classes will be instantiated for chosen features.

Choose the date and time implementation. COleDateTime is recommended for Win32 applications. Uncheck both if you don't need date and time parsing and formatting at all.

Check those APIs you are using in your project. Check also if you need to read back serialized documents written with OG 5.0 or earlier.

Choose classes that you want to use as custom windows in dialog templates. If you use SubclassDlgItem, you don't need to register the window classes and you can turn off the following components.

This branch is only available for the Build Wizard.

Choose components to be linked into the libraries.

Excluding features from being linked into the library and using them in your projects will cause unresolved externals.

Use grid as CWnd or CView.

Use grid as OLE Drop Target or data source.

Cell types that need to be manually registered in your grid. The control factory can’t instantiate these cell types because additional information (resource id for bitmap or pointer to a CWnd object) is necessary when constructing the cell type object.

The code for gridapp sample is located at <stingray-installdir>\Samples\Grid\General\GridApp.

IntelliMouse and scrolltips support.

Formula Engine and worksheet functions.

Pre-built dialogs for customizing the grid appearance or changing cell formatting.

Check the frame window classes you want to use in your projects.

Check those collection classes you want to use in your projects.

Check those classes that you want to use in your projects. Only advanced user should exclude any of these classes.

Use the browser grid as CWnd or CView.

Link ADO classes into the library.

Link ODBC classes into the library.

The Build Wizard lets you choose resources to be included from gxres.rc.

To create the smallest possible grid applications, we leveraged the C++ concept of abstract base classes. Nearly all of the previously described features are implemented through a concrete C++ class that is derived from an abstract base class. Using this concept eliminated any dependencies on the concrete implementation of a specific feature. If you look at the Objective Grid header files (especially gxabstr.h) you see many abstract base classes. All these abstract base classes have been given the name of the feature plus the suffix “Imp”.

You might be worrying that this new concept and the many changes in Objective Grid source code might break your existing applications. We are glad to say this is not the case at all. Objective Grid is fully source-code compatible with earlier versions. All your virtual overrides will still be called the same way they have been called in earlier versions of Objective Grid. Even more, we strongly recommend that you continue to use Objective Grid the same way as before. That means, if you want to customize the behavior of a specific feature override only those virtual methods provided by CGXGridCore (or other related classes). Do not subclass the concrete or abstract base class for that feature. We consider all the abstract base classes and their concrete implementations implementation-specific code. They access protected members in CGXGridCore and the classes themselves are subject to be changed in future grid versions. Don't rely on source code-compatibility if you subclass any of the abstract base classes with the “Imp” suffix. We therefore did also not consider providing many of the concrete class implementation in header files.

Take the “resize cells” feature as example. The abstract base class is CGXAbstractGridUserResizeCellsImp. Its declaration can be found in Stingray Studio <version>\include\grid\gxabstr.h. The concrete implementation CGXGridUserResizeCellsImp can be found in Stingray Studio <version>\src\grid\gxsizeu.cpp. CGXGridUserResizeCellsImp is not declared in any Objective Grid header file and therefore not accessible by your application.

If you want to customize the behavior of "resize cells" there are virtual methods in CGXGridCore that you can override: OnStartTracking, OnMoveTracking, OnCancelTracking and OnEndTracking. These methods are still called in the same way as with earlier grid versions even though their concrete implementation for performing the action has moved to CGXGridUserResizeCellsImp.