Registering CAESAR and the Time/Date Anomaly

We have installed v.4.30 on our computers, and some users have been getting the screen asking them to Register everytime they start the program, even thought they may have registered previously, or chosen not to register. I know how to fix this by deleting the entry in the computer's register, but wanted to know if this is going to happen every time there is a new version.

Also, we sporadically get an error when going to the output that states "the output file is older than the input file and the input will not be able to print." No one has been able to pinpoint this, and we just "work around" it. What is the cause of this, and is there a fix?

Richard Havard


[This message has been edited by rhavard (edited April 24, 2001).]

<font color="#0000ff">Registration</font>

With each new Version of the software, you will be prompted (the plan is only once) to register. This is so that we can maintain "up to date" contact information on users.

Regardless of how you answer the prompt, you should not be prompted again. This prompting is controlled by a registry flag that gets created/set when you answer the prompt the first time.

Unfortunately, on some machines, if appears the registry is not returning the correct flag setting, causing the prompt to appear each time the program is started. We <em>suspect</em> a "permission" problem. To attempt to resolve this, the first build of 4.30 will move this registry flag from HKEY_LOCAL_MACHINE to HKEY_CURRENT_USER. (We put the flag in HKEY_LOCAL_MACHINE so that "shared" machines would only have to be registered once.) You may be asked one more time after this update, depending on whether the "flag move operation" was successfull.

If problems persist after this, I'll move the flag out of the registry and stuff it in a file in \caesar\system.

<font color="#0000ff">Time/Date Anomoly</font>

We haven't been able to pinpoint this either. On entry into the output processors, the program checks to ensure that the output file has a later time/date stamp than the input file. If this check fails, we can only assume that the user may have changed the input after running the job, hence the input doesn't match the output. <em>The purpose of the warning is to alert you to this possibility.</em>

This is just a <em>warning</em>, you can still generate the input echo.

We do have a few ideas on avoiding this problem, so hopefully by Version 4.40 this one will no longer bother users.

------------------
Regards,
Richard Ay (COADE, Inc.)



[This message has been edited by rich_ay (edited April 23, 2001).]