Reprints

If you are going to use the client cursor engine then often it’s a good idea to disconnect your recordset… Disconnected Recordsets The normal procedure for using the Client Cursor Engine is to open your recordset with client side cursors and then disconnect it from the data source. This causes the CCE to pull all of your data out of the data source and effectively marshal it by value to your client.

How to package lots of standard functionality into a CListBox derived class. The problem Several times now I’ve found the need for a pair of list boxes that are linked. Items can appear in either of the list boxes, but not in both. Items can be moved between list boxes, and have processes performed on them. Their order within the list boxes can often be shuffled. The first time I ended up with all of the code to do this spread throughout the message handlers of the enclosing dialog box.

Localise design decisions by writing key application functionality as pluggable COM objects. When the requirements change you just write a new plug in… Introduction Sometimes it’s difficult to see the wood for the trees. You know that using COM is good, but how can you use it? How do you write an app that uses COM? How do you get from IApe and all the text book examples to something in the real world?

It’s rare that code can be viewed as a black box for reuse. If you include design choices and dependencies as valid parts of the code’s interface then it’s easier to explain why reusing nontrivial code is often harder than writing it from scratch. One of the problems that I find when I’m trying to reuse some code is that even if the code is documented well, or written in a style where little documentation is needed, it can rarely be used as a black box.

Making the ADO Client Cursor Engine believe that your rowset is updateable involves jumping through a few extra hoops… Client Cursor Engine Updates It turns out that supporting updates through the client cursor engine is relatively easy. Discovering that it’s relatively easy was extremely difficult. An article that was recently added to the MSDN gives complete and full information on what a rowset needs to support for updates via the CCE to be possible.

The ATL OLE DB Provider templates only seem to support read-only rowsets, and making them support updating of data isn’t as easy as you’d expect! Cursors everywhere First it’s worth clearing up some confusion about client and server side cursors and our rowset. Normally selecting either client or server side cursors is a simple choice between network traffic and local storage. Server side cursors are physically located with the data and in the case of most OLE DB providers that’s probably on the far end of a network connection to your database server.

Adding bookmark functionality is relatively easy and it enables our ADO recordset to be used with a greater number of data bound controls. IRowsetLocate and bookmarks To support some of the more demanding data bound controls we need to support bookmarks. The proxy rowset that we developed in the last article already has some support for bookmarks built in, but the rowset itself doesn’t expose IRowsetLocate, or the bookmark related properties, so the bookmark functionality can’t be used by consumers.

The ATL OLE DB Provider templates appear to rely on the fact that your data is kept in a simple array, but that’s not really the case at all! Implementing a custom OLE DB rowset This article continues from where we left off in the previous article. We have all of the framework in place to provide ADO recordset interfaces on our simple data object. All we need to do now is replace the wizard-generated OLE DB rowset object with one that allows us to access our object’s data.

ADO seems to be the ideal way to expose tabular data from your own COM objects and the ATL OLE DB Provider templates can help! The problem If you already have a COM object that manages data that is naturally tabular, or, if you have a COM object that has data which is often displayed in a tabular form then it would seem sensible to leverage the work being put into ADO by third party data control manufacturers.

Templates are a great way of reusing code, unfortunately MFC makes it hard to write MFC friendly template classes… The problem… Templates are cool. Being able to write code that can work on objects of any type that satisfies the minimum functionality that you require make reusing code considerably easier. No more type-unsafe generic coding methods, like void *’s and macros. Templates solve all manner of problems. Using templates with MFC classes, especially MFC classes with message maps isn’t easy.