CodeBrain/Nova
Nova-Class Pro Java Applets
Main Site
<back | Home | FAQ | Help/Doc | Affiliates | Purchase | Log-In | fwd>
NovaHome

Slider
double
filmroll
grayscape
purchase

Slipper
double
basic
popup
whitescape
purchase

Navajo
Menu

classic
neon
embedded
purchase

iPanner
demo
purchase

Gutenberg
demo full
demo basic
purchase

iFrame
demo one
demo two
purchase

Doc & Help

Purchase

FAQ's

Support
User Log-In

Affiliate
Program

Free
Downloads

Help: General Java Troubleshooting

Routine Errors on Sending to the Server

  • Java .class files MUST go to the server in BINARY - never in ASCII

This is number one on the hit list of common errors.  If you send the .class file up in ASCII, the browser basically can't read the file, since it's looking for a binary Java executable.  Variously, the browser status bar might report a number of errors, often "class file not found" - or it may just sit there dumb as a bag of dead flies.  (This depends on the browser and version.)  If in doubt, send the class file up again.

  • When first setting up, place ALL files related to the applet in the same directory, and make sure you sent ALL of them up

This eliminates guessing games about your pathing, where things actually are, etc.  If you must use codebase= (we discourage this with good reason), don't start pathing things around until you have the applet running!  Make sure your code is written accordingly.

Another extremely common error is omitting to send all necessary files - like image files associated with an applet.  Depending on the applet, that may well stop it dead or throw it into an error condition, so always double-check that everything needed is on the server, and that it is where it should be.

  • Watch your file names and extensions on the server

Some servers - and this isn't that uncommon - have been known to change the case (usually lower-case to upper-case, but sometimes vice versa) of file extensions and - rarely - the file names.  The most common instance of this is an image file that you sent up as image.jpg, but somehow arrives on the server as image.JPG.  Bang - the applet can't find it.  The easiest way to deal with this is just give in, and rename the files on your end to what the server wants.

Even more common, FTP Clients (uploaders, that is) can also cause problems if you don't watch your settings.  One of the best (we think) and most common out there, IPSWITCH's WS_FTP, will give you headaches if you don't uncheck the "force to lowercase" setting in the options.  Other FTP clients often have similar settings.  So, if you see all your files going up lowercase, you know what to do!  Go hunt down the options list in your FTP client and fix that setting to allow uppercase!

(Just as a technical side note, JAVA applet file names are indeed case sensitive and can NOT be changed.  The name of a JAVA applet is part of its internal identity, hard-coded right into the guts of the .class file.  Change the filename of a JAVA applet in any way, even its case, and the applet will belligerantly refuse to function.)
,

.
Common Problems and Errors in HTML Coding for Applets

  • Proofread your Code!

Yes, yes, we know you hate to do it, but you gotta.  Fully 95% (we track this) of all of the e-mail we get about applet problems is the result of one simple thing:  The code wasn't checked!  So when you get all done checking it for the twelfth time?  GO CHECK IT AGAIN.

Java applet tags are not like most HTML, where you can get away with bloody murder and still have the page work.  Leave out a single quotation mark, miss a right carrot - anything, however minor, can blow up a Java applet.  The fool things are dead literal, and they forgive absolutely nothing in the way of coding errors in the <APPLET> or <PARAM> tags.

  • Check all file names - and locations - very carefully

Most applets require some external files to run, frequently image files.  Make absolutely sure that you have the names right.  These file names are also CASE SENSITIVE.  That means if an image is named GeorGe.GiF and you decide to tell the applet it's george.gif - instant problem, the applet can't find it.

Also be wary of just where your files are.  If you use an editor or an environment, especially MS FrontPage, things might very well just not be where you think they are!  This is especially true when you start moving things around, since most editors and environments tend to try to correct the pathing to reflect the changes in file locations - and then screw it up dismally for you!

For the most part, we really recommend using plain old NOTEPAD for setting up applets.  Even with all the work we do with applets, that's what we use.

  • Always do first-time set-up on a clean page - everything in one directory

Whenever you're setting up an applet for the first time, do it from a clean slate.  Start with an empty HTML page, nothing on it but the applet.  Get the applet running exactly the way you want it to - and then and only then move it into the page where you want to use it. Again, this is based on experience across years.  The clutter of a busy page, even for experienced coders, can cause you to miss things that would jump right out at you on a clear, simple page in NOTEPAD.

We also strongly recommend that you start with ALL the files required by the applet in ONE PLACE.  You can get fancy later with pathing and codebase= if you wish - but get the applet running before you confuse matters with that added complication.

  • Applet link parameters must generally be explicit - and live

Although applets readily accept referential paths in their parameters for their own resources (image files, etc.), most applets will not cooperate with you if you try to set link parameters that way.  In most cases, an applet is going to want to see a full, explicit path in the standard format, thus: http://www.sitename.com/page.html (note that the page.html part is optional, but the URL is not).

It's obvious from that, of course, that the links must be live to work...  and that means you usually can only fully test out an applet after you've loaded it to the server.
.

.
Dealing with the Browser Cache - Important!

This is one of the areas that constantly drives newcomers real close to crazy.  You changed an image for the applet - you absolutely know you did - but you open the browser and... the old image is still there!

This can happen with other applet resources, too, but it's most common with image files.  Regardless of whether you use Netscape or Microsoft browsers, you're going to run into it, so pay attention to this one.

The browsers do NOT properly inventory graphical resources (and sometimes others) that are used with applets.  This applies both to when you're live to the 'Net, and when you're working off your hard drive.

The work-around, fortunately, is simple.  When you run into this problem, do the following:

  • Close all running programs if you're using MS Internet Explorer... even having Outlook Express running may disallow proper cache clearing. (You don't need to close everything with Netscape browsers - but it's not a bad idea.)
  • Go to a neutral site.  By that, we mean any site but your own.  (If you try to clear the cache on the page where your applet resides, it may or may not clear.)
  • Clear your browser cache thoroughly.  In MSIE, make sure you clear the offline content as well.  In Netscape, be sure to clear both the disk and the memory cache.
  • Close the browser.

Normally, that will get everything cleared so your latest changes will work properly.  In some few cases, though, you may, however, have to actually reboot (notably on unkempt, improperly updated versions of Windows95).

A side issue related to this that you should keep in mind is, whenever you change the set-up of an applet on an active page on your site, you should probably change the name of that page.  Otherwise, the potential exists for frequent visitors who have not cleared their caches to see old material, rather than your latest revisions. Changing the page name forces the browser to see the page as completely new, uncached material, and eliminates this problem.

=O=

Problem? Questions? E-mail Us! NovaHelp@CodeBrain.com

=O=

.

.
Copyright 1995-2012 by CodeBrain.com
All Rights Reserved
--
Who do WE
Use for Hosting?


We judge hosts harshly. Uptime. Lightning-fast support. Servers that sing. And prices that please. Anything less, and you're history. Our clients won't accept anything but the best. Will you? From demanding music sites like DavidSosnowski to CodeBelly.com to dozens more, we use... Eleven2
.