For the past three months I've been looking at new products or new versions of products that Sybase is introducing and reviewing some of my concerns with them. My general sense is that Sybase is often headed in the right direction, but that they're moving too slowly. In no place is it more obvious than when it comes to the core item that ties all these products together: the DataWindow. In this fourth and final month I'll be looking at the Sybase product that is essentially nothing but the DataWindow: DataWindow.NET.

If you're using PowerBuilder (and since you're reading this editorial there's a good chance you are), the main reason you probably are is because of the DataWindow. For many years it remained unrivaled as a data entry control that was easy to develop with yet it was very powerful. PowerBuilder also implemented many object-oriented programming constructs long before its competitors. However, if object-orientation alone was your key motivator, you now have several other choices.

The question that remains is this: Is the DataWindow still unrivaled as a data entry control? I believe the answer is yes, but the problem is that the competitors are catching up quick. I want to look at one of those competitors, probably the most significant one it has to face. That control is Microsoft's DataGridView, introduced with the .NET Framework 2.0 as a replacement for the DataGrid control. It's the major competitor because most software development shops that are deploying to Microsoft operating systems are inclined to use Microsoft's tools if those tools will do the job. They will only consider alternate tools (e.g., PowerBuilder) or third-party controls (e.g., the DataWindow) if they offer significant advantages over the Microsoft toolset or control. It's only after they have demonstrated that the "native" toolset/control is inadequate that there is even a potential for other toolsets/controls to compete.

What does the DataGridView offer? For one, it's much simpler to control the format of columns in the DataGridView than it ever was in the DataGrid. And the DataGridView allows properties to be dynamically modified based on the data in the columns. That used to be a feature that was pretty unique to the DataWindow. The one main area where the DataWindow still outperforms the DataGridView in this regard is that there is no visual layout designer (i.e., painter) for the column formats for the DataGridView. It's still very 3GLish, in that you have to code the modifications to the column properties and then run the form to see the results. However, I can easily envision Microsoft adding a designer at some future point or some third party developing an add-in designer.

The DataGridView also introduces the option to retrieve data only as it's needed by the control through a "virtual mode." It's not all that straightforward; it requires a considerable amount of coding rather than checking a RetrieveAsNeeded property as you can with a DataWindow. On the other hand, the greater abstraction in the DataGridView's virtual mode also allows the developer a higher degree of control over how the process is implemented.

One of the new column formats introduced with the DataGridView is the DataGridViewImageCell. That means if the select statement accesses a blob column in the database that contains an image, the DataGridView can automatically display that image. The DataWindow gained similar capability when the InkEdit control was added in PowerBuilder 10.2.

One of the other major areas of change is that the DataGridView (and other data bound controls) no longer have to be bound directly to a DataSet/DataTable. Instead, they can be bound to a BindingSource, which is a more abstract layer that in turn is bound to a number of different types of DataSources. In addition to the SqlDataSource (essentially the DataSet/DataTable), there are also ObjectDataSources (classes) and XMLDataSource (Web services). This means that a DataGridView can be fed from a number of different sources, and how the DataGridView operates is largely independent of where the data is coming from.

That's an area where the DataWindow has some catching up to do. One of the features announced for DataWindow.NET 2.0 (currently in beta) is support for binding directly to a DataSet/DataTable. There has also been some discussion about allowing binding to classes that support certain interfaces, such as IList. Both of those make the control act more like a "native" .NET class. But note that such functionality, when delivered, would basically get DataWindow.NET caught up with the .NET Framework 1.x controls (e.g., the DataGrid). What Microsoft has done, while Sybase has been working on catching up with 1.x, is change the paradigm significantly with 2.0.

What should Sybase do? The first thing is to open up the DataWindow so that it can directly accept sources of data other than a database table. In the .NET implementation, they should consider supporting mapping to a BindingSource. In the non .NET implementations, they should be looking at directly supporting Web services and objects that implement iterator interfaces. They need to do that now. If Sybase delivers such functionality in two years, it means that they'll most likely (based on past release schedules) be delivering it at the same time that Microsoft releases the next version of the .NET Framework and another Visual Studio release, and shifts the paradigm out from under them again. They also need to consider functionality that takes them steps beyond where the DataGridView is now. For example, the DataGridView only supports a plain text column style. Now is the time for the DataWindow to implement a rich text edit column style (also mapping to a blob column like the InkEdit control does now).