Commence does well to simplify the tasks involved in developing and deploying a workgroup database. However, since it relies on vbScript as the scripting element there are some elements missing from the scripting environment that makes deploying excellent applications in both small and large workgroups difficult. One of these is the absence of code modularity and reuse.
Commence requires, at times a great deal of scripting to get various tasks done. This occurs mostly in the detail form user interface, where special actions must be taken under various circumstances to insure proper data formatting and form interfacing. One of the nice things about Commence is you can make multiple detail forms on the same category that represent a detail item in a different view. However, since these forms all act on the same category, then it is common for all of them to contain much of the same code. This means code-duplication - and that's a bad thing! The DumontDLL strives to reduce and possibly even eliminate code duplication by providing various code storage and interface tools that allow detail form vbScript codes to be placed in library-like files, and included as needed. The DumontDLL tries to make this type of code reuse and inclusion a trivial matter. (See Scripting Include Functionality for details)
Another area of Commence that is particularily limiting is some of the built-in automation functionality of its own. These areas include multi-date expressions and calendar item management, outlook and palm synchronization, the absence of item deletion notification and control not to mention foreign database synchronization in general. All of these functions are neatly packed into binary code internal to Commence and cannot be changed operationally. If outlook synchronization doesn't "quite" work, then often you will have to make some weird workarounds. For instance, if your application employs selective synchronization with read/write permissions, then functions like import/export, outlook and palm synchronization are likely to fail unless you set them up very carefully. You are often forced to create a myriad of agents and script components to accomplish the task of synchronization properly. That's fine if you can get the job done in the end, but what about maintainability? Something particularily missing in Commence is object-documentation, and when you have a pile of agents and bits and pieces of scripts and forms and whatnot all to fix the synchronization module that doesn't "quite" work, and none of it is documented (how do you put a comment or description on an agent) maintaining such a "solution" can be a real problem. With the DumontDLL, synchronization modules are built-in, designed to be flexible, and if the code isn't quite right for you, the source code is available for you to change it to suit your needs directly. Yes, the DumontDLL is open-source - change it to your heart's content.
Having said all of that, I still think the Commence(tm) database is one of the coolest databases to use for office/workgroup implementations. Its synchronization engine is one of the best I've ever seen! Even despite the 100 field limitation (the DumontDLL has a solution for that as well) I have not seen any other synchronization engine in any other database product that is quite as easy to implement, manage and deploy as the one provided by Commence. The integration between the database definition screens forms and reports is unmatched (IMHO).
So, the whole point of the DumontDLL is to simplify coding by providing code-reuse facilities, enhance the Commence executable by providing additional features and generally make the life of the programmer a little bit simpler. It's not perfect, but it provides me with the enhancements to Commence that takes care of the issues I have when working on it.
Why NOT Dumont?
One argument is it's "hard to deploy". Well, yes, it's "yet another application" to deploy within a workgroup. And "yet-another-application" is not what we want or need. So, you have to weigh the value of the DumontDLL against the effort to deploy it. To simplify deployment I have created some simple scripts in the Dumont category within Commence(tm) to aid in the distribution of the DumontDLL. The scripts are simple, and once set up properly, deployment is transparent - even in a workgroup environment. So, like anything, it's a mix of good and bad. In my book I'd rather make my programming a little easier and maintenance of my programs a little easier if it means a little planning and setup up-front to get it all installed and running. I hate coming back months or years later looking at agents in Commence and asking "what was I thinking?" I don't have the brain power for that. The DumontDLL aleviates a lot of that.
Note, however, that Dumont isn't doing anything that hasn't already been done by dozens of Commence code gurus. ALL of the techniques used here have already been suggested and/or used elsewhere in other capacities. If you wanted to implement all this functionality yourself using only native vbScript you could! I don't know why you'd want to but you could. In fact, I had attempted that very thing and found vbScript to be just a little bit lacking in code organization - something C++ can be very good at. Also, I found vbScript to run relatively slowly for basic processing functions. Generating 10 multidate calendar items in vbScript (the way I had laid it out, with object-orientedness) took 10 seconds! That was too long! VbScript was not the answer. So I've turned to C++.
All Dumont is doing is taking those same code practices that are already in use by hundreds, maybe even tens, of programmers, and wrapping them up in a nice little DLL and (hopefully) making the life of the programmer (me) a little easier. No magic going on here. Everything here comes from the Commence Help files, and from the most fantasic Commence developers resource http://www.freedomcomputing.com website.
If you want to tear into the source files and start hacking please feel free to do so. I have a habbit of over-commenting my comments! Some of them might be outdated or just plain wrong as I've changed my mind while coding and did not necesarily update the comments. But, I did my best. Just note that Dumont is published under the LGPL software license which means you cannot take the code in Dumont and use it in your proprietary (closed source) application (this does not hold true if you're simply "using" the DumontDLL library). Any changes you make to the Dumont source code *must* be contributed back to the original author (me again) so that I can include them in the base package, and/or if I don't, then at least YOU are required to publish those changes (along with the original Dumont) so that everyone can benefit. (I think this is all true about GPL and whatnot - I'm still learning interesting and exciting things in the most fantastical and mysterious world of software licensing).
Please remember that at this stage of the game Dumont is very much a work in progress. In other words, USE WITH CAUTION. Check the dates at the bottom of these help screens, they will tell you how recently I compiled this help file and possibly what version the project is at. Know this... if you do use Dumont, and something breaks, I'm not paying for it! There is no warranty expressed, suggested, hinted at or even implied (if that's not redundant enough I don't know what is). Don't come crying to me if it don't work - I'm a one-man show over here. If you want to sue me over something I wrote that doesn't work very well the most you'll probably get is a couple of broken down VW's and two dogs that don't listen very well.
So, having said all of that, enjoy, happy coding, and contribute back if you can!
~ ~ ~ ~ ~ ~
Source Code without Comments is like a Cranberry Garland
without the berries. Comment your Code!
Commence Database User Support Group Forum
~ ~ ~ ~ ~ ~
Author: Mark Petryk
Lorimark Solutions, LLC