Scripting Include Functionality

Dumont provides support for "Script Includes" - that thing that's vastly missing from vbScript. Script Includes allows you to place script fragments in individual files and have them get pulled together into a single script - just like the advanced languages.

To use the scripting support in Dumont a few things need to be addressed. For one, remember that a script include is particular to a particular database. Dumont doesn't support (at present) machine-global scripts, although it may be able to in the future. This means that a database() object MUST exist for Dumont to fetch a script include for it. If you are fetching a script on a form while that form is open, then, by default, a database() object does exist. On the form the database object can be acquired by the following:

 dim cmcDB: set cmcDB = Form.Application.Database    ' get THIS database
             -- or --
 dim cmcDB: set cmcDB = CreateObject("Commence.DB")  ' get first opened database

Once you have a database() object you can basically do anything you want with the database, including getting a DDE conversation, opening a cursor, getting database-specific path information and whatnot. Therefore, since it is your desire to use the Dumont Script Include functionality on a form while in that form then using the Dumont script include engine is fairly straight forward:

 dim ddll: set ddll = createObject("DumontDLL") ' connect to Dumont
 dim dfrm: set dfrm = ddll.Form(Form)           ' wrap the form
 ExecuteGlobal dfrm.DB.Script( "" )   ' include the script
 ExecuteGlobal dfrm.DB.Script( "" ) ' include another script

What Dumont does in this exercise is open a cursor to the DumontCategory (which it is able to do because it has access to the Form.Application.Database object) and looks for a particular 'Name' entry, in this case "" and "". When it finds the entry its looking for it reads the contents of the Value field and returns that to the caller. The function ExecuteGlobal simply executes the code blindly.

One thing to note about this method of including scripts is that debugging is much more difficult. Often the only message you're receive from a coding error is that there was some sort of error on the form on "Line 2" of all things! Hardly useful!

To address that issue, it is possible to enable the Microsoft Script Debugger and have it pop-up with a code-shower (not a code-editor) displaying the lines that are generating the error. The procedure for setting this up is as follows:

Install the Microsoft Script Debugger
I cannot now tell you where you can find the Microsoft Script Debugger. It, like most things on the microsoft website, moves around alot. If you're going to google for it search for the msscrdbg.exe file, which is the main debugger executable. In my install directory I have only ten files, mostly dll's, which constitutes the debugger. If you're having trouble finding the debugger shoot me an email at and I'll see if I can help you find it.
Modify the Registry
A windows registry setting must be changed to allow this debugger to automatically invoke on a scripting error. That setting can be found here:
 \\HKEY_CURRENT_USER\Software\Microsoft\Windows Script\Settings\JITDebug = 0x01
If that setting has moved (in the new up and comming Vista) please let me know so that I can update these notes.
Write Some Buggy Code
Ok, if you need help with this then you really shouldn't be reading this document!
Please Note that it is NOT required to install the Microsoft Script Debugger in order to be able to use the Dumont Script Include functionality. It's just that you'll probably want the debugger once you start working with the Script Include since any mistake you make inside an included script is completely shrouded in a useless error message.
That's It! You should now be able to use the Dumont Script Include functionality to start modularizing your code. What's nice about this also is an included file can include additional files! Beware though, if a file gets included twice then you're likely to have problems.

But, consider the following... You have a include item "" in your "Dumont" category, and that item contains code that is common to all your scripts. Now you're working on your Calendar scripts and, as usual, your calendar category has several forms, depending on the type of calendar event. But, you also have code that is both unique to the calendar category, and common to those forms. What you can do is as follows:

Dumont Item: ""
 ' This code is Common to my entire application
 Public CLIENT_NAME = "XYZ Pork Chops"
 Public i, j, k
Dumont Item: ""
 ' This code is Common to any calendar item
 ExecuteGlobal ddll.DB.Script("")
 ExecuteGlobal ddll.DB.Script("")

 Sub AssignStaffMeeting()
  ' do things here to make sure everyone attends
 End Sub
Detail Forms, Calendar Category, All Scripts
 ' Code to go on a specific calendar form (has to be duplicated for all forms)
 dim ddll: set ddll = createObject("DumontDLL")
 dum dfrm: set dfrm = ddll.Form(Form)
 ExecuteGlobal dfrm.DB.Script("")
As you can see from the examples above, the only code that needs to be duplicated in every form script file is the three-lines of Dumont Script Include stuff. That's a pretty small amount of code to have to duplicate across your entire application! The rest all comes out of the Dumont items and gets easily shared between all your various forms and scripts. The only limitation I've come across so far is that any Commence item Memo field can only store 32K bytes of text data. That may sound like alot but depending on how you write your code (I comment liberally) that 32K can get used up pretty quickly.

None the less, this is a powerful way to reduce the effort it takes to maintain vbScript code within your application.

~ ~ ~ ~ ~ ~
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