More from Microsoft.com
. . . then Chotank questions the recommendations
From: "Simon Cooke (Exchange)"
To: "'Chotank@aol.com'"
Subject: RE: Code Sample??
Hey there...
--------------------
But now to the comments you made about the code and browsers:
You will have to give me a reference citation that says something to the
effect: "You cannot use Toolkit for Applet-related downloads." Otherwise, I
cannot accept your opinion on this.
--------------------
Well, page 331 of Java In A Nutshell 2nd Edition states:
"java.awt.Toolkit:
The Toolkit class defines a few methods that you can use directly: the
static method getDefaultToolkit() returns the default Toolkit that is in
use. getScreenSize() returns the screen size in pixels, and
getScreenResolution() returns the resolution in dots-per-inch. getFontList()
returns the names of supported fonts. sync() flushes all pending graphics
output, which can be useful for animation. In Java 1.1, get PrintJob(),
getSystemClipboard(), and getSystemEventQueue() are also of interest."
From the online Sun Java 1.1 documentation at
"This class is the abstract superclass of all actual implementations of the
Abstract Window Toolkit. Subclasses of Toolkit are used to bind the various
components to particular native toolkit implementations.
Most applications should not call any of the methods in this class directly.
The methods defined by Toolkit are the "glue" that joins the
platform-independent classes in the java.awt package with their counterparts
in java.awt.peer. Some methods defined by Toolkit query the native operating
system directly."
So, if you're writing an Applet, I'd recommend that you use the exposed
methods in the Applet object to do your work; that way you've got a better
guarantee of things working correctly on all browsers.
-----------------
Your statement about the old code is very overblown. The MyCHOFlow.java
code
was written long before the release of JAVA 2.0. And, as you know, the
compiler lists which classes are depreciated/deprecated. Therefore, the
programmer knows which parts of the code are outdated. According to Sun,
outdated code should run anyway, and it does on Netscape.
-----------------
Hey, all I said was that you're using a lot of deprecated methods!
-----------------
As to using the Sun appletviewer for setting my own expectations of browser
compatibility, that is what I have done. All Applets are first evaluated on
the appletviewer before loading on the web site.
The point is that Netscape will run the code and IE won't. In my mind, that
makes IE inadequate. Taking a position that Netscape is inferior because it
will do what Sun expects a browser to do is not a good argument as I see it.
Your statement that "the Netscape JVM does a lot of things wrong" is an
expected Microsoft line in comparisons like these.
-----------------
As I stated in my response, the experiences with Netscape that I was talking
of were my own, pre-Microsoft (ie. before October 1998) experiences writing
AWT based code. As GUI coordinator for a large pan-European project (ACTS
project 112; Trumpet), I was called on to ensure that not only would our
code work on a variety of browsers and versions of Java, but to also provide
solutions to work around browser and platform incompatibilities, for a
number of systems; Netscape and Internet Explorer (and the AppletViewer),
and on Windows, Solaris and HP-UX.
However, that aside, the important point I was trying to make was that you
should try your code on the appletviewer in all cases, and only where
browsers behave differently to the appletviewer should you start to pass the
blame onto the browsers. As it seems that you already do that checking step,
it looks like something else is the cause of the problem. Though I'd be
interested to know if the appletviewer you were using was from a JDK
downloaded directly from Sun, and was running on a Sun JVM, or if it was
from Symantec, or somewhere else.
[other comments deleted by Chotank]
-----------------
Since you are on the Visual Studio UI Controls team, rather than the JVM
team,
which I thought was the situation when we started this exchange, I think my
next correspondence should come from the JVM people.
This exchange will be posted on the web site.
Thanks again,
Avon Edward Foote
P.S. Since you are in the UK, I wanted you to known that recently I had an
informative tour of the Electronic Telegraph, the internet edition of
London's
Daily Telegraph. Most pleasing was the tea break overlooking the new
Millennium
Dome at Greenwich from the 12th floor of Canary Wharf.
-----------------
Ah, actually, I'm not - I used to live there, but I recently moved to
Redmond, WA.
Hopefully we'll be able to get to the root of this. I'm going to hand you
over to someone better placed to answer your questions, and we'll see what
evolves.
Si
ps. Hey... just had a thought. You're a BBC Networking Club Alumni, aren't
you? Remember the "win a modem by describing the internet in 150 words or
less" competition? That was me :)
Now read Chotank's reply (edited for web display)
Date: Wed, 10 Feb 1999 06:34:01 EST
Simon,
Sorry, for the delay with a reply, but I have been waiting to see if any readers of your comments could find flaws in the recommendations.
No one has raised a red flag, but I am still waving mine.
If Toolkit should not work for applet-related downloads, why does it run fine in IE 5.0 (beta)? You already know that Netscape 4.0 (and forward) handles the MyCHOFlow.java code. And if you go to www2.una.edu/communications/ and follow the JAVA-powered link, you will find an implementation of Toolkit which WILL load an image into a separate applet frame, when running under IE 4.0. Look for the UNA lion in the upper-right corner window.
David Flanagan (O'Reilly, 1997) may not be saying what you and I have interpreted him to say. Should somebody ask Flanagan?
As to the appletviewer -- it is Sun's. I am running the JDK 1.1.
Were you a member of the BBCNC and or on staff at PIPEX? The BBC should have kept the organization as international focus for BBC fans. But then, the BBC is changing very rapidly. I am looking forward to enjoying BBC America as soon as I get my Dish TV/PC installed.
I have read your posts to the java.advocacy newsgroup. Your advice and continuing interest is terrific -- thank you for taking a part.
Avon Edward Foote chotank@aol.com
Date: Sun, 7 Feb 1999 22:27:54 -0800
This abstract class defines methods that, when implemented, create
platform-dependent "peers" for each of the java.awt Component types. Java
supports its platform-independent GUI interface by implementing a subclass
of Toolkit for each platform. Portable programs should never use these
methods to create peers directly - they should use the Component classes
themselves. A Toolkit object cannot be instantiated directly.
Component.getToolkit() returns the Toolkit being used for a particular
component.
http://java.sun.com/products/jdk/1.1/docs/api/java.awt.Toolkit.html#_top_
From: Chotank@aol.com
To: simcooke@Exchange.Microsoft.com
Subject: Re: Code Sample??