<%@ Page language="c#" AutoEventWireup="false" %> SandGrid Documentation

SandGrid User Guide

Introduction

Back to Table of Contents

Goals

SandGrid is a flexible data presentation control. It encapsulates most of the common data presentation formats and exposes hooks for a great deal of control over its behavior. Its hierarchical nature means it can replace the ListView, TreeView, DataGridView and other data list controls.

Architecture Overview

The architecture of SandGrid is such that most commonly-used grid features are supported while still being one of the fastest grid products available for .net. As a developer new to SandGrid, understanding its basic architecture will help you quickly familiarise yourself with it and get it integrated into your applications.

The InnerGrid class represents a grid. It has Rows and Columns collections and all the properties you would expect from a grid, but it is not a visual component: it does not derive from Control. This is because in order to support the windowless nested grids feature we had to separate the grid from the display. The SandGrid class is what you will normally use to put a grid on your forms. It has a PrimaryGrid property which exposes the main InnerGrid within, and mose of the InnerGrid properties are echoed on the SandGrid class.

Grid products are complicated and usually have a great deal of properties in order for developers to fine-tune their behaviour to their specific needs. SandGrid can be used as a functional replacement for ListView, TreeView and DataGrid controls by changing combinations of these properties. At design time we expose a "Configure Grid" command that changes whole blocks of properties in order to quickly mimic any of these controls.

Starting in version 2.0 we now provide a SandTreeView class, which is far simpler than the SandGrid class and is designed explicitly for TreeView-like behaviour. All properties not relevant to tree structures are removed and it doesn't even have a public Columns collection since typically there is only one column in a tree. Of course, the PrimaryGrid property is still there for fine-grained access to the powerful grid inside.

Once you have a grid on your form (either a SandGrid or a SandTreeView) you'll need to give it some columns and then populate it with some data. Both of these activities are described in great detail later on, but from an architectural standpoint it's important to know that columns transform and display data, whereas rows store and obtain the raw data. This allows for extensibility of integration at various levels

Columns

A grid cannot function without columns to format, parse and display data. SandGrid columns are tremendously powerful and are represented with the GridColumn class and its various specialised subclasses. The Columns collection of the SandGrid class can be managed at design time; it's easy to add a few columns to a grid and set their header text and imagery.

There is an entire page devoted to working with columns later in this documentation.

Rows

Rows are in charge of obtaining and storing raw data values. The most basic method of populating GridRow instances, once added, is similar to a ListView: you add cells to the Cells collection and each cell contains data and formatting information which is passed to the parent column for formatting and display.

You can add rows at design time. When you do this, ensure your columns are already created because then cells of the correct types will automatically added to your new rows so it's easy to then set their data in the property browser.

A lot of the power of SandGrid lies in its ability to obtain data dynamically through various means, a lot of which involve having no cells present at all. These are slightly less intuitive than the simple Cells collection but lead to significant performance gains. They are covered later in this documentation.

Speed

SandGrid is one of the fastest grids on the market for windows forms. It achieves this with pervasive performance optimizations all through the product, but there are still some best practices to be aware of when using the grid.

There is no BeginUpdate and EndUpdate pair of methods because the grid does not need to be told when a large set of changes is made. All triggers to measure, layout and paint are queued and happen when changes stop being sent. In a few specific instances this can result in unexpected behaviour; for instance if your code populates the grid then immediately enumerates the Groups property of the grid, it will be empty because the grid has not yet updated its layout. A quick call to the PerformElementLayout method will force a layout update to occur.

We use a highly-optimized text engine for drawing all text in the grid, and it automatically switches between GDI and GDI+ rendering as appropriate. When owner-drawing text in the grid yourself we recommend you use our static IndependentText class to do so, as text will be drawn faster and will use the best technology available at the time.

Next: Populating with Data