It is extraordinarily robust. You can give it all or none of the following options and it will adapt. (i.e. if you leave out one of the graphic URLs, it will be fine, and will even make the best of what it has left in an intelligent way...) Java currently supports jpegs and gifs. *Sigh*. Someday we'll have a lossless >8-bit standard. And someday we'll have more than .au format... And someday netscape (or whoever) will fix the bug that causes all sounds to stop playing when one of the ovelapped sounds stops...
You don't have to use this for what it was designed for, of course. You could give it 1 by 1 window size, no images and have just a normal sound clip looping and that would give you background music...
Or you could just use it as a simple interactive image (i.e. poke somebody in the face and they scream... wow!)
Relative URL's in HiBut can do almost anything and still be parsed. Descending up (down?) a tree with ../ will stop at the drive or server name even if there are extras ... you can have ./ and ../ INSIDE of the path (like ./../../java/../java/temp/) and it'll do just that... You can set your own custom URL base to navigate from (and even that can be partial and it'll try to resolve it from the codebase of the applet or the document URL, depending on which you set it to do...) REMEMBER that the first character as a / means "the root" so with a base of http://www.www.www/temp/hi/ a relative path of "/me/you/" gives http://www.www.www/me/you/. Put ./ if you must have an intro slash.
Also - the URL will keep the trailing / if it's there and keep it off if it's not (when parsed as a relative URL...)
Transparency - fact or fiction? You can fake transparency with this applet. Java does not support true transparency. To fake it, set the background color using the color-related params to match as nearly as possible your page's background. Then you can use transparent gifs over the top of that and you're off and running. Not perfect, but hey, we do what we can. See the discussion on the troubleshooting page about the Javascript alternative.
Image Params - The URL's for the images (the active image appears when the user clicks and releases on the button, instead of clicking, dragging off, and then releasing... This is a good place to put something that says "wait", since the java link can sometimes be slow...)
Sound Params - are the same things as the images, just sounds... Their states will function independantly of the images... Remember that java currently only support 8k mono u-law compressed .au files...
Sound Looping Params - whether or not the sound loops when played. ("yes" or "no")
Text Params - the text to show in the menubar at these states. Will basically display whenever it should, regardless of the images or sounds being there, but will NOT relocate itself automatically like the images and sounds do (i.e. if you want the normal text to always be there when the mouse goes over, supply it four times to each of these tags... Or just set highlighttext because the text will remain there (unless cleartext is set) and will only comeup when the mouse is over the applet... THE TEXT WILL FOLLOW THE IMAGE RULES, though, for displaying, so if the active image never comes up the active text never will either. I believe that this is always true. If you want active text but no active image, don't supply an active image and set useactiveimage with value=yes and the text will show.
URL - the URL to link to upon activation. If none supplied than no link will take place. The URL will keep the trailing / if it's there and keep it off if it's not (when parsed as a relative URL...)
target - an option for the URL link... i.e. _top, or whatever. (see an HTML primer and look up the <a href=...></a> tag...
verbose - "yes" means it prints out information relating to what images it couldn't load, URL malformations, etc... Defaults to no.
name - the name to use when reporting stuff (see "verbose")
cleartext - Whether or not to clear the text in the display bar when the mouse leaves the applet. ("yes" or "no".) Defaults as no.
cleandraw - whether or not to "clear" the applet before writing the images. If you're using transparent gifs you can set this to "no" and they will lay over each other like so many sheets of celluloid. Defaults to yes so the applet first draws a rectangle in the background color over everything and then draws the potentially transparent gif over that. (Don't worry, it uses double buffering for this to eliminate any flicker...)
usebase - which base URL to use when resolving partial URL's. Either "code" or "document", meaning the URL of the applet's name.class file or the URL of the document containing the applet. Defaults to document.
custombase - a URL to use when resolving partial URLs. Supply a URL. If it is a partial URL the program will resolve it according to the "usebase" parameter above. If it's a full URL it will override any usebase setting.
useactiveimage and useactivesound - determine whether or not to use the active image. Both of them, if not sepcified as "no", will turn on if an active image or sound is supplied via the param tag. A "no" will override any supplied active images or clips. Keep in mind that supplying a bogus but well-formed URL for the active sound and useactivesound=yes will cause silence to be played, as there is currently no way (that I know of) to check to see if a sound clip has loaded correctly. If useactiveX is "no" the highlighted image and/or sound (respectively) will play after full selection (activation) of the button. Also remember that the sound and images work independantly. So useactiveimage=yes and useactivesound=no will get the active image with the highlight sound playing over it. Also remember that if the active image doesn't load right for _whatever_ reason or isn't supplied the normal image will be put in its place if useactiveimage=yes. This kind of makes sense - it will indicate a change - normally the highlighted image would be there...). The same goes for the active sound and seactivesound=yes, though again, we can only tell if the active sound's URL is messed up, not the sound itself. Anyway.
stoponleave - Should non-looping sounds stop when the applet is suspended? (I.e. when the browser leaves the page, etc...) Defaults to "yes". If not, sounds will play out first. Non- looping sounds always stop because they will play until you quit the browser or the applet stops them. Note that sometimes sounds that aren't looping may stop anyway if substitution took place in the four sounds. This is because the variables that determine whether or not a sound loops come from the <param> tags, and the way the sounds get moved around is with pointers. So stopping a sound because it's a looping sound is a mistake if some other sound which isn't looping is using the same sound resource object... The ways around this (as far as I know) just were not worth it...
interruptsound - should the sounds cut each other off or layer over eachother? Deefaults to yes (cut off), because currently there is a bug either in java or Netscape that cuts off all playing sounds whenever one of the finishes. Since buttons tend to have short sounds that are frequently ovelapping if this is true, this is a problem... Use "no" at your own experimental risk...
bgcolor - the applet's background color. You can either use a hex value (form ffffff, #ffffff, or 0xffffff) or you can name one of Java's built in colors (black, blue, cyan, darkGr[e/a]y, gr[e/a]y, green, lightGr[e/a]y, magenta, orange, pink, red, white, yellow). I made it take the gray/grey forms because "gray" is cooler. And you can even put in "casey" and get roughly my favorite color. The color defaults to black (#000000).
bgcolorred, bgcolorgreen, bgcolorblue - the component version of the above. Specify (in decimal) 0-255 for each. The above will override this. The color defaults to black (#000000).