Spread Windows Forms 7.0 Product Documentation
Understanding the Underlying Models
Support Options
Spread Windows Forms 7.0 Product Documentation > Developer's Guide > Understanding the Underlying Models

Glossary Item Box

You can use models to customize the user experience with the spreadsheet and extend the functionality for your particular application. This is an advanced topic in some respects because you can do many tasks without ever using the models. Through the Spread Designer or through properties of the shortcut objects (such as Cells, Columns, and Rows), you can affect many of the changes that define your spreadsheet. But because the sheet models are the basis for all the shortcut objects, using models is generally faster than using shortcut objects. For example, in code using the shortcut object to set a value:

    FpSpread1.Sheets(0).Cells(0,0).Value = "Test"

would be equivalent to using the underlying data model method:

    FpSpread1.Sheets(0).DataModel.SetValue(FpSpread1.Sheets(0). GetModelRowFromViewRow(0), FpSpread1.Sheets(0). GetModelColumnFromViewColumn(0), "Test")

To understand fully how Spread works and to make use of many of the features and the customizations available to you as a developer, you should understand how to use the underlying models. As a set, the sheet models correspond to the basis of all the objects and settings of a particular sheet. Each sheet has its own set of models. If you have multiple sheets in your Spread component, then each sheet has its own set of models.

As described in the Product Overview, several aspects of the sheet in the component are governed by underlying models. The models are shown conceptually in this diagram.

Sheet with Underlying Models Diagram

These topics can help you customize the component using models:

But using the models can be very complicated to describe completely, because there are many interfaces involved. Each model class implements a number of interfaces, and each model has one "model" interface which must be implemented to make it a valid implementation for that particular model. All references to the model classes are through the interfaces, and no assumptions are made as to what interfaces are implemented on each model (except for the "model" interface which must be present). If the model class does not implement a particular interface, then that functionality is simply disabled in the sheet (that is, if IDataSourceSupport is not implement by SheetView.Models.Data, then the DataSource and DataMember properties are not functional). For complete lists of these interfaces, you can look up the overview for the default model classes in the Assembly Reference. The descriptions that are given in this topic are only meant as an introduction to the use of sheet models.

© 2002-2014 ComponentOne, a division of GrapeCity. All Rights Reserved.