This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
place db-1x3.db and suncertify.properties in same directory
suncertify.properties is NOT contained in runme.jar
app will allow db-1x3.db to be re-located and will provide JFileChooser to access it in "server" or "alone" mode
app will insist that suncertify.properties NOT be relocated.
if properties file not found by app (searching in current directory), it will be regenerated with default values.
I am a bit confused with the comment that "app will insist that suncertify.properties NOT be relocated" along with "if properties file not found by app (searching in current directory), it will be regenerated with default values". Does this mean that if you cannot find the suncertifies.properties file in the current working directory then you will be copying the values in the suncertifies.properties file in the directory containing the jar file?
Thanks for your interest. I am assuming that the current working directory is the directory that contains runme.jar. If you think this assumption may lead to trouble, please tell me. Regardless of whether it is or is not, I'm using "." to specify the path needed to find suncertify.properties. If you think this may lead to trouble, please tell me.
When I posted this topic, I intended that if suncertify.properties was missing from the directory that contains runme.jar, that the program would automatically create a new version of suncertify.properties (with default values) in this directory. My intent was to demonstrate that I was handling the situation where the user had inadvertantly lost or corrupted the file. Naturally, I intended to place corresponding entries in choices.txt and userguide.txt.
I have since changed my mind. I've tentatively decided to:
Include an additional copy, suncertify.backup in this same directory.
Have property-file-corruption or property-file-missing situations trigger a pop-up message that refers the user to a specific area of the userguide.txt file and then immediately System.exit(1) et al.
Mention in choices.txt that both the client and server (gui) Help menu items provide direct access to the user guide.
Also mention in choices.txt that it is assumed that the user has indirect access to this guide via a text editor.
I welcome your reaction to the above + the corresponding userguide.txt entry (below). I don't want to anger the evaluator with my arrogance.
author and jackaroo
The way I read the instructions, I got the feeling that Sun were implying that there was no correlation between where the jar file was located or where the database file was located, and the current working directory.
So in theory, I could have
the database file in c:\data
the executable in c:\program\scjd
and I could start the program from c:\temp
But I think that your original concept would have handled that scenario quite happily.
[Side note: I think it would be extremely unlikely that the assessor would try such a scenario, but I think your program would have to be able to handle it if they did.]
Personally I think your current proposal (exiting if suncertify.properties does not exist) is not very user friendly, and I don't think that it matches the requirement that "All configuration must be done via a GUI, and must be persistent between runs of the program. Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory." I think that if the properties file does not exist then you would be better off offering default values in the GUI and creating a new properties file.