Aubrey,
I agree :-)
I should have mentioned perhaps that in my application the user will not modify source code usually found in programs.
The application needs a bunch of parameters the user should be able to modify. At first I planned to put them in a configuration file
like this one:
[ClimateChamber]
Enabled=TRUE
MinTemp=-50
MaxTemp=90
TempChgTimeoutInMin=120
TempTolerance=3
UnloadMinTemp=10
UnloadMaxTemp=30
UnloadHoldTime=10
DelayIns=5
[ClimateChamberPort]
IsRs232NotTcp=TRUE
Name=COM4
TimeoutInms=100
Baud=9600
DataBits=8
Parity=none
StopBits=1
xonXoffNotRtsCts=TRUE
[TempLogging]
TimeSpacingInsToFile=120
TempSpacingToFile=5
TimeSpacingInsToDisplay=120
In fact I have many many more parameters like these.
For the user this is very ugly to maintain and error prone, and for me it means to develop a program which would interpret this stuff,
that means, first checking for presence of all parameters and then checking all types and values. Because from time to time the number
of these parameters will change, I would have to change my program too.
So I decided to let the compiler do part of the task. For every of the three groups of parameters above there will be a separate procedure; the parameters of a group will become the formal parameters of the procedure. So the compiler will be able to check if all parameters exist at all and if the data types are correct. Calling such a procedure will write the values of the parameters into some data structure.
The std encoded file contains the procedure calls representing the parameters above. The text system of BB was a great help in formatting the data in a table like manner. Adding comment lines to the table will give the user a better understanding than just the parameter names of the config file above. Additionally the procedure names are written in blue color and underlined and are associated with links into a documentation file which gets opened when a procedure name is clicked by the user (again BB is great in simplifying matters by offering such facilities).
Now lets get back to the "dirty document":
The procedures writing the parameter values to some data structure are called when a command button is clicked on the GUI. My intention was to guarantee consistence between contents of the data structure and contents of the configuration file. This consistence will get lost if the user would modify the configuration file, click the button (i.e. updating the internal data) and closing the editor view WITHOUT saving his modifications.
Disabling the button on the GUI as soon as the editor view is dirty prevents this problem.
Best regards,
Rainer
----
To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
Received on Wed Jul 18 2012 - 16:11:38 UTC