<- previous index next ->
Have you ever been editing for a long time, then suddenly, crash?
Were you able to recover most if not all of your work?
A user may spend many hours on a GUI program and expects reasonable
protection.
As appropriate, some applications save automatically:
at some time interval, after some amount of input or at some key
place in program execution.
Other applications save only when the user specifically chooses
to save. Think about what is appropriate for your application.
The technical process of saving user data can depend on programming
language and operating system. A few applications have a lot of
data and complex structure in the data and thus use a full
relational database. Most application use a simple file for saving
and restoring user data.
Even though operating system crashes are much less common, there
are still occasional power outages, network outages, network
disconnects or your pet terminating you application.
(One of my cats likes to jump six feet onto my keyboard while
I am typing. This causes random chaos until the cat is
safely on my lap.)
Thus, the programmer must consider all places the application may
be abruptly terminated and protect the users data from loss.
The "bad method":
Read in the users previous work, save the users present work by
writing the new data into the old file. Consider what remains if
the application is abruptly terminated just as the first record
is being written: The old data is lost, the new data is not saved,
the user has lost everything.
A "better method":
Read in the users previous work from a permanent file, close the file.
When a save is to be executed, create a new file with a
backup temporary name, write the users new work to the new file.
Flush and close the new file. Open the permanent users file for
writing, open the backup temporary file read-only, copy the
backup temporary file to the permanent file, flush and close.
Then, delete the backup temporary file. This method at worse has
preserved the users original work. Upon startup the application
should look for the backup temporary file name first, (it will
always be the latest user work) and if not found, look for the
users permanent file, and if not found create an initialized
user permanent file.
Other versions of A "better method":
If provided by your programming language and operating system,
once the backup temporary file is closed, rename or "move" the
backup temporary name to the permanent file name. Both files should
be in the same directory and thus only a directory update is
performed. At least one of the files should be available even when
there is an abrupt termination during the rename.
For a game, please provide a "pause." It may be a phone
interruption or a biologically urgent need. Then, there
needs to be a "resume." Since the game does not know how
long the pause will be, the state information should be
written to a file. The computer could shut itself off or
some other activity may kill the game. The "resume" may
test if the state is still in RAM and quickly continue,
or determine the state must be restored from a file.
What file format should be used for saving?
That depends on the application. My first choice is always an
plain text ASCII file that I can look at (and fix if necessary)
with any text editor (or word processor).
For a large amount of numeric data, that is saved and restored often,
an unformatted binary file may be more appropriate. It turns out
that formatting binary data to ASCII numbers and formatting back is
a very CPU intensive process. The ASCII form usually makes the
file larger and thus also increases the disk read and write time.
The amount and type of data varies according to the application.
For a game or puzzle or lesson you would keep some statistics and
possible user identification. For example, arcade game style is
to have the highest scores displayed with the players initials.
At the end of each game the permanent file is read and the new
score inserted, in order, if it is higher than the lowest score.
Usually the maximum number of saved scores is limited.
For a one user game, the save file and present status, might be
presented similar to FreeCell statistics:
For an object oriented graphics editor the save file might look like
rectangle 10.3 12.5 4.0 3.0 filled 255 0 0 0 255 0
circle 5.7 19.2 5.0 outline 128 128 128
line 22.7 39.4 22.7 59.4 3 0 0 255
text 14.6 50.2 courier 14 "this is my text" 0 0 0
It is the application programmers choice to use fixed fields
or just a sequence with the interpretation based on the first field.
Above, the rectangle has a lower left x,y at 10.3 12.5,
a width and height of 4.0 and 3.0, it is filled with red and
outlined in green.
The circle has center at x,y 5.7 19.2, radius 5.0 and is
just outlined in medium gray color.
The line goes from x1,y1 to x2,y2 with line width 3 and color blue.
The text has a lower left at x,y 14.6 50.2, using courier font 14
point and black.
The words might be replaced with code numbers for more convenient
programming but less convenient editing to fix problems (user
or program). Beware, only add larger code numbers when modifying
your application. Otherwise, getting an old saved file can be
a real surprise. The voice of experience.
In many programming languages it is more convenient to use space
as a separator than to use comma. Fixed fields or just sequential
may depend on a particular programming language.
For an application where the user was creating 3D objects, like
teapots or skulls, the .dat file is convenient.
This file starts with two numbers, the number of points and the number
of polygons. Then the x,y,z of the points followed by the polygons.
Each polygon has a count of the number of points followed by that
number of indices of points, the first point being point 1.
The "C" files include:
datread.h for Utah Graphics .dat .det
datread.c provide reading and writing this file type.
test_datread.c test and demo program
test_datread_c.out test and demo program
cube.dat
drop.dat
Also, see cube.dat below.
The Java files include:
datread.java for Utah Graphics .dat files
test_datread.java test and demo program
test_datread_java.out
For a graphics scene editor that places objects, the users work might be
saved as a file such as:
device: lab6_input1.rle
postscript: lab6_input1.ps
jpeg: input1.jpg
debug: 5
viewport: 400 400
coi: 0 0 0
hither_yon: 1 100
observer: 4 1 20
angle: 8.0
light_position: 10 30 30
light_color: 1 1 1
object: drop.dat
color_type: 1 1 0 0
illumination_parameters: .2 .8 1.0 50
shading: phong
rotate: 45 30 60
scale: 1 1 1
translate: .25 -.36 0
object: drop.dat
color_type: 1 1 1 0
illumination_parameters: .25 .75 1.0 10
shading: phong
rotate: 0 0 180
scale: 1 1 1
translate: 0 .6 0
object: cube.dat
illumination_parameters: .3 .70 0.0 10
shading: phong
color_type: 1 1 .5 .5
scale: 2 2 .1
translate: 0 0 -.5
object: cube.dat
shading: phong
color_type: 1 .2 .9 1
illumination_parameters: .25 .75 1.0 100
scale: 2.0 .2 2.0
translate: 0 -1.0 .5
end
Note that the type of input ends with a colon.
An object in .dat format is placed in the scene with rotations,
scaling and translations that are simple matrices as
covered in an earlier lecture. Shading may be faceted,
phong or none. Color is ARGB and illumination parameters
are ambient, diffuse, specular and shiny. See teapots.c for
examples. The above scene when rendered appears as:
The shapes of objects are stored in .dat files for this "run6"
renderer. The cube.dat is
8 6
-0.5 0.5 0.5
0.5 0.5 0.5
0.5 -0.5 0.5
-0.5 -0.5 0.5
-0.5 0.5 -0.5
0.5 0.5 -0.5
0.5 -0.5 -0.5
-0.5 -0.5 -0.5
4 1 2 3 4
4 5 6 2 1
4 8 7 6 5
4 4 3 7 8
4 2 6 7 3
4 5 1 4 8
0.0 0.0 0.0 0.0 0.0 1.0 0.0 1.0 0.0 4.0 6.0 9.0 1.0 -1.0 -1.0 1.0 -1.0 1.0 100.0 100.0 100.0
|---VRP---| |--VPN-------||--VUP----| |----COP---| hith yon |--- window------|
|------Light----|
This example contains additional, optional, information for rendering.
Some RayTrace programs use the .nnf Neutral File Format,
plain text file described in nff.txt
Do not confuse this with nff2 or 2.0 that is totally incompatible.
Other file types may be used for texture mapping, terrain, or
backgrounds. For example terrain.bw in SkyFly.
On a different subject, there are a lot of text editors around.
Source code for a Motif version is
w6a.c another of the w*.c collection
Source code for wxPython is in three files (compile in this order):
w6wxbar.py compiles into a .pyc
w6wxed.py compiles into a .pyc
w6wx.py runs the text editor
Python3 used to make cube of 27 smaller cubes:
cube64.py3 source code
cube64.dat makes .dat
without rotation from light_dat.java
with p and h rotation from light_dat.java
Then a smaller cube made from 8 smaller cubes:
cube27.dat 27 points
If you think you have trouble saving users work:
<- previous index next ->
Many web sites on Java GUI, AWT, Swing, etc.
Many web sites on Python wx, tk, qt, etc.