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:
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( "common.inc" ) ' include the script ExecuteGlobal dfrm.DB.Script( "thisForm.inc" ) ' 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 "common.inc" and "thisForm.inc". 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:
\\HKEY_CURRENT_USER\Software\Microsoft\Windows Script\Settings\JITDebug = 0x01
But, consider the following... You have a include item "common.inc" 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:
' This code is Common to my entire application ' Public CLIENT_NAME = "XYZ Pork Chops" Public i, j, k
' This code is Common to any calendar item ' ExecuteGlobal ddll.DB.Script("common.inc") ExecuteGlobal ddll.DB.Script("getThisOneToo.inc") Sub AssignStaffMeeting() ' ' do things here to make sure everyone attends ' End Sub
' 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("calendar.inc")
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