A general explanation of how to use the sample code.
* NOTES ON THIS MONTH'S PROJECT(S)
Notes on any particular issues or problems relating to this month's code.
************
USING THE SAMPLE PROGRAMS
The sample programs accompanying this column are provided as Java source code on the SuperCD. They have all been developed and/or tested in Symantec's Visual CafΘ 1.0 and Asymetrix SuperCede 1.0. For the time being, all source code in this and subsequent columns will be based on version 1.0.2 of the Java Development Kit (JDK) from Sun Microsystems (unless stated otherwise). At present this is the most widely supported version of the JDK, though the new JDK 1.1. will gradually replace it.
You should, in most cases, be able to compile our sample code using any JDK 1.0.2 compatible compiler. However, the Java language specification is evolving and some compilers support subtly different features. For example, in Visual CafΘ you can restrict the scope of variables using the pair of keywords 'private protected' but in Asymetrix's SuperCede you must use the single keyword 'protected'. While our sample programs aim to avoid these kinds of incompatibility, there may nevertheless be occasions when you will have to make some changes to the code.
As a rule, to use our sample files in your development environment, you should follows these steps:
1) Create a new directory on your hard disk.
2) Copy our sample source file or files (with the extension '.java') into this directory.
3) Create a new 'empty' project in your development environment.
4) Add or import the '.java' source file or files to this project.
You should note that, due to the way in which different development environments handle visual design, you may be unable to edit the layout of our sample forms on screen. The forms should display correctly when you run the applications, however.
NOTES ON THIS MONTH'S PROJECT(S)
* MODAL DIALOG BOXES
The files Vectors.java and VectorPlusFrame.java both contain code that shows a dialog box defined in MsgDlg.java. This dialog box should, logically, be modal - i.e. it should block access to the calling form until the user has clicked OK.
However, due to a bug in Sun's JDK 1.0.2 libraries, modal dialogs may refuse to shut down again in the PC (Win32) implementation. This bug may have been 'fixed' in some Java development products - the modal dialog woks fine in Visual CafΘ 1.0, for example, but not in SuperCede. For this reason, the dialog in the sample apps has been implemented as non-modal. That is, the dialog box is invoked with this line:
MsgDlg md = new MsgDlg(this, false);
The false parameter here specifies non-modal. To invoke it as modal (not recommended!), alter the line to:
MsgDlg md = new MsgDlg(this, true);
For work-arounds to the Modal Dialog bug, see Sun's on-line documentation:
Our sample programs make use of entities called Enumerations to scroll through items in Vectors and Hashtables in code such as:
for (Enumeration e = v.elements(); e.hasMoreElements(); ) {
// Cast element to MP to retrieve name and position fields
anMP = (MP)e.nextElement(); }
Enumerations are described more full in 'Introducing Java', PC Plus issue 127. If you missed that issue, here's a quick summary:
Java's Enumeration provides a simple way of scrolling through a list of items such as those in a Vector. It has two useful methods:
hasMoreElements() - returns true if there are more elements.
nextElement() - returns the next element in the Enumeration.
While the Enumeration itself may be fairly easy to understand, you may have more problems making sense of the 'for' loop, particularly if you aren't a C programmer. Although the 'for' loop I've used may look complicated, it isn't essentially any different from a loop that counts from 1 to 10. The first statement of a 'for' loop initialises a variable. Here it happens to be an Enumeration variable that is initialised to the elements of a Vector:
Enumeration e = v.elements();
This is not fundamentally different from initialising an int variable with a numeric value, 'int i =1', though in the present case it is a lot more useful. Next I've placed a test condition:
e.hasMoreElements();
This causes the loop to continue executing until the condition evaluates to false - that is, until all the elements have been processed. The third statement of the loop, which normally increments a value, has been omitted (there is nothing after the semi-colon). This is because a statement within the loop itself increments the loop counter:
