There's a JDK 1.0 compiler bug if youi declare some methods as final.
If they are small enough the compiler will inline them.
However this will cause access errors if the inline code
references some private functions.
N3.0 seems to get its paint routine graphics context clip rectangle wrong,
ie it is often too big, causing unnecessary screen rewrites.
IE3.0 and appletviewer seem to get it right.
Hey, images and ImageObservers are quite neat!
I got my applet init() method to getImage().
I just put a call to drawImage() in the applet's paint routine.
I did not expect it to work straight away, as the image would not have arrived.
In fact it did, as drawImage() was passed the applet as its ImageObserver parameter.
The applet, being a component at heart - which is an ImageObserver -
had its imageUpdate() called;
the default component imageUpdate() called paint(), and hey presto...
However... if you call getWidth() or getHeight() for an image then
the default Component imageUpdate() does not do a repaint.
So, make sure you do a call to drawImage(),
even if getWidth() or hetHeight() says the image is not there. Got that?
In IE3.0, if you do a frame window resize before the frame is shown
then the size is not used.
You have to do the resize after you have called show().
Unfortunately, there is a slight flicker of a larger window.
N3.0 has neither of these problems.
From appletviewer you can call System.getProperties()
and then System.getProperty() for each property found.
In N3.0 System.getProperties() causes an exception, though System.getProperty() works.
In IE3.0 both calls usually cause security exceptions;
however System.getProperty("browser") returns "ActiveX Scripting Host".
This might be a security hole:
This technique allows you to access private variables/methods in a class,
as long as you know what their names are.
Make a dummy replacement for the class you are trying to hack.
Make public the variable/method that you want to use.
Now remove your dummy. The variable/method should now be accessible.
N3.0 frame window handling:
In NT you expect Alt+F4 to close a window.
Instead Netscape passes this key press to your program,
which usually by default will ignore it.
So you could hard-code this to close the window if you wanted.
IE3.0 lets Alt+F4 close the window - correctly, in my opinion.
I wanted to have a Label as a status text in a form.
My first attempt was to initialise the window status text Label to be "".
However the layout process restricts the Label area to just this string.
My next approach was to initialise it to the largest string that I wanted it to be,
ie the size of another label, above it.
I then relied on receiving GOT_FOCUS messages to set the Label to the desired text.
However this did not work for IE3.0 and Appletviewer as these messages are not received.
My final solution resizes the status Label to the desired size at the first opportunity.
Note that you cannot do this correctly straight after setting up the container (why?)
I do the resize in my showStatus() routine, the first time it is called.
To round it off,
I include some extra calls to set the status so it works reasonably well in IE3.0.
GridBagForm.Tab() returns the status text;
previously it relied on the GOT_FOCUS handler to set the status text.
I also set the initial status text to be that required initially.
StringTokenizer is pretty bad if you use delimiters other than white space characters.
While using a delimiter of ";", ie a semi-colon,
I expected string "xxx;;yyy" to find three tokens, with the second one blank.
Unfortunately, StringTokenizer just returns 2 tokens, xxx and yyy.
You can specify to return all tokens, but this is a poor solution.
Please: have another option to return blank tokens between delimiter characters. PHDStringTokenizer fixes this problem.
Is there any way of working out what size window will fit a given form layout,
ie so that window can be resized to minimum fit?
Using preferredSize() works for frame windows resizes.
IE3.0 displays menus with name "&File" with the F correctly underlined as a short-cut.
PC N2.02 does this as well.
PC N3.0 does not do this.
What about other browsers on other platforms?
What does a paintComponents() in an applet's paint() do?
If you miss it out, all the components still get drawn.
TextField: getting edited value
In my Applet's keyDown() method, I find that the user has typed a character into a TextField.
However if you call that field's getText() then it has not processed the character yet.
For simple cases this is OK as you can just add on the received event key.
However it soon falls down if any editing, cursor movement, etc. are being done.
Calling super.keyDown() does not alter the TextField's value.
How do I get the edited value of the TextField?
*Trapping the keyUp() method works, but it would be interesting to know
how to handle keyDown() properly.
PS Is there any way of sending messages?