It takes some time for The Dotfile Generator to read all the files of the modules. By that reason it has the capability to bytecompile the modules. This means that The Dotfile Generator saves the information, which it has read from the module, into a file. This file is then read the next time the module is invoked, instead of sourcing/calling the procedures which make the modules. This may give the user a problem if the procedure creates global variables, which it uses in e.g. the Save function. The following example should show this:
... global rgbValues set fonts [exec showrgb] set names [getFontNames $fonts] set rgbValues [getRgbValues $fonts] ListBox fontName -entries names .... Save { ... print "RGB value of font name $fontName is"\ [nameToRgbVal $fontName $rgbValues] ... }
The importent part of this example is that the global variable rgbValues contain the rgb-value associated with the name of the fonts. This information is first used in the Save function, where the function nameToRgbVal refers to this variable.
If the module has been bytecompiled, then this variable will not exist, as the procedure which should have created it, never were invoked. The solution to this problem is to tell The Dotfile Generator that it has to save this variable into it's bytecompile file too. This is done with the SaveVars procedure.
The example above will then look like this:
... global rgbValues set rgbValues [getRgbValues $fonts] SaveVars rgbValues ...
To see how you can set default values at run time for bytecompile files, please refer to The init Function