DumontEXE 0.0.1
DumontEXE - Dumont Uses Multitudes Of Nifty Techniques
Note:
This project has not been released yet! This documentation is here for reference purposes only. If you are interested in using this project in one of your Commence databases (like I am) then shoot an email to mark@lorimarksolutions.com

Dumont: A small program designed to extend the programming capabilities of the Commence Database API.

The DumontEXE project represents Phase-II of a scripting enhancement effort designed expressly for the Commence database system available from the http://www.commence.com website.

The Dumont project started somewhere in late 2002. It was an attempt to improve on the Commence API which, quite honestly, as cool as the Commence database tool is, the API is a mess. All the programming interface is through visual basic, and as easy as that can be at times, deploying truly robust applications is difficult when your only primary programming interface is vbScripting. It is for me anyhow.

That early Dumont application did little more than allow manipulation of memo fields (aka; large text fields) in an .ini file type of format, in an attempt to break the 100 field limit of the Commence database.. The effort to get even that to function reliably was excrutiating, since, at that time, I knew just about nothing about COM and the process of automating applications through it.

Late in the fall of 2006 I decided to rewite Dumont in an open-source platform using the Qt development library from http://qt.nokia.com/ . My desire there was to produce a truly feature-rich programming extension library for Commence they way I had envisioned - by subclassing cursors and rowsets and fields and connections and so on - and to make it open-source which would mean that anyone would be able to contribute.

The primary hurdle there was COM. The Qt programming library, in its open-source version offers no COM support. I had to develop this component by hand. Holy, moly, what a task that was! It took me six months of hard research and testing and prototyping and reading and researching just to get my first COM interface to function. I'm not talking about writing a COM client, something that talks to Outlook or Word, but a COM server - an entirely different animal.

Qt offers a COM extension in their purchased version, but I wanted to keep this an open-source product, so I have refused to bite the bullet and pay for a license, as tempting as it has been. Believe me, it's been tempting.

In the spring of 2007 I finally had a functioning DLL that had a COM interface and did a pretty-darned good job of subclassing Commence objects, including cursors and rowsets and fields and connections, just like I had envisioned. You can get to the documentation and source code for that project here: http://dumont.showoff-db.org I put the package into production and started using it immediately. I built in to it a feature for quickly including script portions into other scripts, allowing me to modularize my code in my projects. I added a changeLog functionality that captured in an xml file every change to every field and connection on every item. It worked great.

But, there were a few things missing. For one, I couldn't easily produce a running object table for Commence. If you are unfamiliar with this concept, a running object table allows any application from any location to get a copy of any other application. In the case of Commence, you acquire a 'handle' to the database from a form by specifying: Form.Application.Database.getCursor(...). This function works, and gives you a handle to a cursor in your currently open database. If you are running a .vbs (external application) to Commence, and you want to get a cursor on a category, you do it slightly differently. You would say; createObject("Commence.DB").getCursor(...) or something to that effect (I'm just talking here, I'm not trying to learn you how to program).

Well, in those two examples, if you have two databases open, how do you 'specify' which database you want a handle to? In the Form.Application version, you get the current database you're in. In the createObject("Commence.DB") version you get... who knows, the first opened database? the last? It doesn't matter if it's not the one you want, and you can't direct windows to give you specifically a handle to a specific database.

Enter the DumontEXE project.

What the DumontEXE allows you to do is "Register" your application instance with Dumont. When you do that the registration is filed by database name. What the DumontEXE then makes available to you is a get() function that will get a specific instance of a database by name.

This means, then, that for every database you open, if you register it with Dumont, then that same database will be available to any script. I'll save the details for another help page, but suffice it to say that if you are currently running a script on a form in one database, and you want to fetch something from another database, it is now a trivial matter.

The DumontEXE project has all the same features and functionality as the DumontDLL project, plus a few extras (such as the DumontROT). Plus it has a few general improvements to some of the technology since the first iteration of the DumontDLL suffered a little bit of design-on-the-fly implementation degredation.

There are several clear advantages to using the Dumont API wrapper. For one thing, while the API is completely backwards compatible with the Commence API, the Dumont offers significantly improved API functions. These improvements result in cleaner looking vbScript code. Cleaner looking code is easier to understand code. And easier to understand code is easier to maintain. Dumont also provides additional features that are not easy or readily available through the Commence API without a lot of special vbScript coding gymnastics. With Dumont all these gymnastics are trivial, natural and taken care of internally. This translates into a more efficient API. Dumont can do things in ways that are just not possible in other frameworks. The result is your vbScript programs will run faster, and be more reliable.

None the less. Have a look. Play around. Give it a try. Comment back. And, by all means, jump on in and help! Programming in C++ is easy and fun.

A good place to start is the page on the cmcDatabaseApi namespace. That page is more-or-less at the heart of the project. We are also working on a series of videos for better understanding of the component capabilities.

You can find those videos here: http://www.youtube.com/watch?v=Sx4JWp5GBoA

Author:
Mark Petryk ~ Lorimark Solutions, LLC.
 All Classes Namespaces Functions Variables Enumerations Enumerator Properties




~ ~ ~ ~ ~ ~
Source Code without Comments is like a Cranberry Garland
without the berries. Comment your Code!
 
Commence Database User Support Group Forum
http://newsgroup.showoff-db.org/
~ ~ ~ ~ ~ ~
Author: Mark Petryk
Lorimark Solutions, LLC
mark@lorimarksolutions.com