Table of Contents:
I. General Tips
II. Debugging
III.Compiler
IV. Native Java
V. Swing
VI. Deployment and Jar Tools
VII. Revision History

I. General Tips

API Reference
Due to the immense size of the reference material for the Java APIs, the documentation for the Swing 1.0.3 API and the Swing 1.1 API are not available in the same help file. For this reason, two API help files are provided on Disk One CD. These files are:

\extra\Apiref\swing103\help
\extra\Apiref\swing11\help

When you install VisualCafé, the APIRef.hlp and the APIRef.cnt files that contain Swing 1.1 documentation are installed in your <VisualCafe>\Help folder. To access the Swing 1.0.3 documentation, simply copy the APIRef.hlp and APIRef.cnt files from \extra\Apiref\swing103\help to your <VisualCafe>\Help folder. All API documentation is also available through the Javadoc Viewer.

Additional information about the APIRef help file is located in \extra\Apiref\Apiref.html.

Distributing the JVM
If you want to distribute your applications created with VisualCafé along with the WebGain Virtual Machine, you need to use the JavaSoft JRE instead. The Symantec JIT and WebGain JVM included with VisualCafé are not redistributable. JavaSoft has licensed the Symantec JIT for redistribution in the JRE. The JRE is Sun's Java Runtime Environment and is freely redistributable. Please visit http://www.javasoft.com/ for more specific information regarding the JavaSoft JRE.

Form Designer and relative URLs
When I open a project in the Form Designer, the dialog for Dial Up Networking appears. If I log on, all is well. If I cancel, VisualCafé "hangs" for several minutes.
The use of relative URLs (for example, IMAGES/test.gif) can cause this behavior on some systems. To avoid it, use absolute URLs (for example, file://C|/.../PROJECT/IMAGES/test.gif) during design time and then switch to relative URLs for deployment.

JFC Documentation
Sun's JFC documentation is located in the <VisualCafe>\Documentation\JFC directory. The Java2 documentation is in the <VisualCafe>\Java2\Docs\api directory.

Keyboard mapping changes
The keyboard mappings for the text editor in VisualCafé were updated in version 3 to match many other common Windows editors. To get the familiar key mappings from earlier versions of VisualCafé, go to the Keyboard tab of the Environment Options dialog and select "vcafe2" from the File drop-down list.

Back

Top

Migrating projects from previous versions of VisualCafé
When migrating projects from previous versions of VisualCafé, it is recommended that you create a backup of the project source files before performing the migration. Such a backup will be valuable if manually added code is modified within the tagged sections that is not in keeping with VisualCafé's code generation format.

Permissions to run WebLogic Server
To enable VisualCafe to properly work with the WebLogic Server, the permission java.security.AllPermissions; must be added to the general grant block in the weblogic.policy file.This change is necessary when the WebLogic Server is running in a non-WebGain VM.

Project Type and EJB tab
If you want to change an existing project type to an EJB Application, you may have to close and re-open the project before the EJB tab displays in the Project Options.

Red Hat Linux
If you are using Red Hat Linux 5.0, you will need to modify the shell scripts 'debugvm' and 'ddservices', as well as the file 'defaultprocessfactory.properties'. Each of the files that need to be modified contain comments that explain the modifications needed. The scripts will be in the directory where you unpacked the cross-platform support tar file. See <VisualCafe>\platforms\platforms.txt on the Disk One CD for more information on the tar file.

The properties file will be in the zip file contained in the tar file. You will need to extract the properties file from the zip file, edit it, and then zip up the modified file properties file. The respective commands for this are:

unzip [ zip file ] com\symantec\itools\distdbg\defaultprocessfactory.properties

and 

zip -0 [ zip file ] com\symantec\itools\distdbg\defaultprocessfactory.properties

Remote VM in Process View
When you use Step Into to start an Enterprise Bean server/client project pair, the process view does not show the remote VM until another step is performed, or until you reach a breakpoint.

Running applets in Microsoft Internet Explorer
If you encounter problems running applets in Internet Explorer, please install the Java plug-in from Sun available at: http://www.java.sun.com/products/plugin. This will ensure that Internet Explorer is running with the latest VM from Sun. If you continue to encounter problems, expand symbeans.jar to your \windows\java\classes directory using a third party unzip utility. Symbeans.jar is located in the <VisualCafe>\bin\components directory.

When executing applets, Internet Explorer uses the system environment CLASSPATH. If your applet does not execute, verify that the CLASSPATH used by your project is the same as the system CLASSPATH.Versions of Internet Explorer affected are:

• Version 5.0 running in Windows NT and Windows 95/98.
• Version 4.0 running in Windows 98.

Back

Top

Security
To simplify configuration, allow debugging, and allow local execution of Java2 applets, VisualCafé installs a modified java.policy file into the directory <VisualCafe>\Java2\lib\security\.

The pertinent security settings in this file are:

// VisualCafe Additions to relax security checking within its Java2 VM

grant {
permission java.security.AllPermission;
permission java.lang.RuntimePermission "modifyThread";
permission java.lang.RuntimePermission "modifyThreadGroup";
};

Version Control
When you check in a project and the .vep file has been marked read-only, remember that if you add, remove, or rename files, or if you change project options, you will be unable to save them except with the File | Save As command. Checking out the .vep file through VisualCafé to mark it read-write will result in a merge of the .vep file overriding the local changes. Make sure that the .vep file is checked out before making any changes to ensure that your changes can be checked in.

When using version control with SourceSafe, the VisualCafé project root is by default where the .vep file is stored on your hard drive. All project files added to SourceSafe must be in that directory or in a subdirectory of that directory or SourceSafe will generate errors since it can not map the files. Currently it is not possible to change this root directory in VisualCafé.

Notes:

• The .vep file is a binary file.
• It is not recommended that the .vpj and .ve2 files be kept under version control. If you choose to check them in, make certain that they are not marked read-only. If you do, VisualCafé will be unable to open the project.

VisualCafé Open API
The VisualCafé Open API supports both C++ and Java interfaces for writing plug-ins and integrating with the environment. Many vendors have implemented integrations using the VisualCafé Open API. For the latest information on integrated solutions and also to download the Open API SDK, please visit http://www.webgain.com/Developers/openapi/index.htm.

WebLogic and database drivers
If you start WebLogic Server manually with a deployed bean that uses a third party database driver, you need to add this driver in the weblogic.class.path for connection pool to get instantiated. The additional classes used by the bean also need to get updated in the weblogic.class.path.The WebLogic Server needs to be started with the -Dweblogic.class.path=Driver class file. Please refer to the WebLogic Server documentation for more information.

If an entity bean is created with a third party driver like Oracle thin-client or WebLogic Oracle driver, and at least one data member of the type BigDecimal or BigInit, the WebLogic Server throws ejbc failure errors. The workaround is to map the data item to a different data type.

Back

Top

II. Debugging

DDservice logging process
Debugging with plugged in JDK 1.3
Debugging applets in Microsoft's Internet Explorer
Debugging applets in Netscape Navigator
Debugging with a pluggable VM
Debugging a servlet project
Debugging with multiple classloaders
Debugging enterprise bean on Solaris
Hiding VM while debugging

DDservice logging process
To turn on the basic logging of the process creation, use the command 'ddservices -verbosespawn'.

To help debug remote processes, you can turn on basic logging of process creation by starting ddservices.exe from the command line passing in the option -verbosespawn. This causes ddservices to print out the command it uses to start debuggable VMs.

Debugging using plugged in JDK 1.3
You cannot remote execute or debug using Sun's JDK 1.3 as a pluggable VM. The workaround for this is to rename the hotspot directory. VisualCafé may still throw an exception that says KeyManagementException: Key addition not allowed. You also need to move the -classic entry to the top of the list in the jvm.cfg file.
To debug locally using jdk 1.3, set your environment to run java.exe in JDK 1.3.

1. Copy platforms\SetUp.class from the CD to a temporary directory and run java SetUp from the command line.
2. Define the platform you are using (optional).
3. Select Generic 1.2 for Windows.

Debugging applets in Microsoft's Internet Explorer
The Microsoft browser does not support JNI, the native code required by Sun's JDBC-ODBC Bridge. Microsoft has its own version of the JDBC-ODBC Bridge, which can be obtained by downloading the Microsoft SDK for Java from their website.The output while debugging on IE is directed to IE's console window.

Debugging applets in Netscape Navigator
VisualCafé supports Netscape Navigator version 4.5 or later. You can download Netscape Navigator from http://www.netscape.com/download/index.html.

Occasionally applets may fail to run in Netscape Navigator. If your applets fail to run when executed from VisualCafé, they should run if executed a second time while a browser window is already open.

Netscape will issue some security violation exceptions when you attempt to execute or debug applets from within VisualCafé. To avoid this security constraint, please add the following options to your prefs.js file:

user_pref("unsigned.applets.low_security_for_local_classes", true);
user_pref("signed.applets.local_classes_have_30_powers", true);
user_pref("signed.applets.low_security_for_local_classes", true);
user_pref("signed.applets.verbose_security_exception", true);

Notes:
1. This file states that it should not be edited by hand. In order to add entries to this file, you must first close all running instances of the Netscape Navigator. You may then edit the file manually.

2. You may see a message in the Java console, "# Security Exception: checkpropsaccess.key". This message can be ignored.

3. Most security errors can be avoided by publishing the applet to a web server.

For more information on Netscape security please refer to the following URLs:

http://developer.netscape.com/support/faqs/champions/security.html

http://developer.netscape.com/library/technote/security/sectn3.html

Back

Top

Debugging with a pluggable VM

VisualCafé includes support for JDK 1.1.7a and 1.2 automatically. If you wish to debug into another VM, use
the following checklists to configure the wrapper classes in additional Pluggable VMs.

Java2 Platform (JDK 1.2):

To add the wrapper classes:

1. Unzip the classes in:

<VisualCafe>\java\lib\Wrappers\generic-JDK-1.2.zip.

2. Insert them into the JAR file <JDK1.2>\lib\tools.jar.

3. If you haven't set up a JDK 1.2 VM profile in VisualCafé, go to Tools | Environment Options | Virtual Machines to set one up. See the online Help Topic "Virtual Machines Tab" for more information.

4. In the .2 VM profile, add these files to the front of the "Compiler Classpath" and "Classpath (VM Executable)" entries:

<JDK 1.2>\lib\tools.jar;<JDK1.2>\jre\lib\rt.jar;
<JDK1.2>\jre\lib\jaws.jar;
<JDK1.2>\jre\lib\i18n.jar

5. Press <F5> or Select Project | Run in Debugger as you normally would to start debugging.

Note: If you use the JDK 1.2 provided by VisualCafé, these options are set automatically.

JDK 1.1.5 - 1.1.6 - 1.1.7

To add the wrapper classes:
1. If you haven't set up a JDK 1.1.x VM profile in VisualCafé, go to Tools | Environment Options | Virtual Machines to set one up. See the online Help Topic "Virtual Machines Tab" for more information.

2. In the .1 VM profile, add these files to the front of the "Compiler classpath" and "Classpath (VM Executable)" entries:

<VisualCafe>\java\lib\Wrappers\generic-jdk-1.1.X.zip; <jdk1.1.X>\lib\classes.zip

3. Press <F5> or Select Project | Run in Debugger as you normally would to start debugging.

JDK 1.0.2
VisualCafé does not support debugging in JDK1.0.2, although you can compile. Please use VisualCafé 1.0x for full JDK 1.0.2 support available from the VisualCafé Update Center at http://www.webgain.com/download.

Other Sun JDKs
If there are no debugging wrapper classes for a JDK, there might be strange behavior. For example, you can start a debug session with JDK 1.1.4, but some breakpoints might not get hit.

There are certain features and commands in the VisualCafé debugger that require a WebGain extended VM in order to work properly. These features are:

1. Pausing the app in the debugger while it is executing via the Debug | Pause command.

2. Expression Evaluation. This includes the following:

1. Data Tips
2. Evaluate Expression command in source window
3. Conditional breakpoints
4. Typing in values in the Watch window
5. Modifying variable values in the Variables window

3. Incremental debugging, including the Debug | Update Now command and modifying a file and saving it to invoke the patch mechanism in the debugger.

4. Method restarting. This is the ability to pop out of a method to "restart it". This includes the Debug | Restart Method menu item.

5. Decompiling support. When using a decompiler to see source code for classes that do not have debug info, you must be debugging in VisualCafé using a WebGain modified VM with the appropriate Redefine class support added.

If you are in a situation in VisualCafé where you are debugging your classes inside a VM that has not been extended by WebGain, then the above commands and features may or may not work. In some cases, the UI does gray out the appropriate menu items, but not for all cases. Circumstances when debugging inside a VM that does not support the above commands and features include:

1. In the Virtual Machines tab of the Environment Options you specify a non-WebGain VM and use this VM in VisualCafé.

2. You invoke the "debug in waiting VM" command and attach to a VM that is a non-WebGain VM such as a VM on UNIX.

In general, it is best to avoid the above features and commands when you are debugging in a non-WebGain VM.

Debugging a servlet project
While debugging a servlet, if the servlet page does not appear in the browser without forcing a refresh, change the VCAFE_SERVLET_TIMEOUT property in the sc.ini file. The current default is set to 5 seconds.

Debugging with multiple classloaders
Since WebLogic Server 5.1 service pack 2 supports custom classloaders, the same class may be loaded by more than one classloader.This causes VisualCafé to display more than one breakpoint and only the breakpoint in the most current class will be used. To enable breakpoints to be hit, set the following option in the sc.ini file:

Make webgain.tools.debug.DontUseClassLoadNotify=true an optional VM argument.

To change an enterprise bean, choose Project | Options | EJB tab | Manage Deployment Target and add webgain.tools.debug.DontUseClassLoadNotify=true to the Optional VM Argument property.

Debugging enterprise bean on Solaris
You need to download the reference implementation of Java2 currently available on the Sun website to enable debugging of a enterprise bean deployed on a WebLogic Server 5.1 on Solaris. This resolves the issue of stepping into the WebLogic Server on a UNIX machine and the debugger seems to continue to the next breakpoint. For more information refer to documentation on http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/threads.html.

Note: Reference implementation is only recommended for development purposes . For differences between reference implementation and production release is given in http://java.sun.com/products/jdk/1.1.7B/solaris-product-comparison.html.

Hiding VM while debugging
To provide default security to the VM you are debugging into by hiding it from other users looking for VMs, use Tools | Environment Options | UML/EJB tab | Manage Deployment Target. The property Exclude other attachments has a checkbox. When this checkbox is selected, the VM is hidden..

Back

Top

III. Compiler

Note:When you change the VM to JDK 1.1, you are still using the 1.2 compiler.

There are now compact drivers, sj.exe and sj.dll, which load independent compiler DLLs, sj12.dll and sj11.dll. The sj12 compiler DLL supports JDK 1.2 and WebGain's new native implementation. It is fully compatible with Sun's javac compiler for JDK 1.2.3. The sj11 compiler DLL supports JDK 1.1, is fully compatible with Sun's javac compiler for JDK 1.1 and supports WebGain's previous native implementation.

By default sj12.dll is loaded, even when JDK 1.1 is targeted in the environment settings.The sj12 compiler is of higher quality but slightly more restrictive than sj11. Using the sj11.dll compiler is discussed below.

The JDK 1.2 Compatible Compiler - SJ12.dll
The new JDK 1.2 compatible compiler, sj12.dll, includes the following features:

• New compiler is equivalent to Sun's javac 1.2, including many bug fixes
• New native support which addresses previous issues reported with the old native support
• RMI support has been updated to be compatible with rmic 1.2
• Various speed/memory improvements
• Enhanced usage information, specify sj -help-all for the complete list of flags and options.
• New environment variables plus some old ones renamed to have SJ_ prefix for clarity
• -langid NNNN switch for international message support
• sj12.dll has a specific environment variable, JFLAGS12, to help with backward compatibility
• -Xverbosepath displays the CLASSPATH used by the compiler
• Direct support for .class files to native executables

The JDK 1.1 Compatible Compiler - SJ11.dll
Changes to the previous 1.1 compiler include:

• Supports -sysclasspath <path> to pass the system classes to the compiler, this path is always first in the CLASSPATH
• JFLAGS11 environment variable to help with backward compatibility
• Some bug fixes
• -langid NNNN switch for international message support
• API environment variable renamed to SJ_SYSTEMDOCDIR, as in sj12
• Memory improvements
• -Xverbosepath displays the CLASSPATH used by the compiler

It is recommended that you use the old 1.1 compiler only for "old native" compilation to prevent deprecation errors.

To use the old 1.1 compatible compiler in the VisualCafé environment:

1. Go to the page: Project | Options | Compiler.
2. Choose the dropdown Compiler Category: Advanced.
3. In the Custom compiler flags field enter -backend:sj11.

To use the sj11 compiler on the command line, specify -backend:sj11 as the FIRST argument to sj.exe.

Back

Top

IV. Native Java

GEO Emblaze
GEO Emblaze components are not supported in Native Applications in this release of VisualCafé.

Native compiler
When using third party classes (and components) in a native code compiled project, you must do one of the following two tasks:

• Include the source for these classes as part of the project
• Pre-compile the source for these classes to a native DLL and have the import library for that DLL listed in the Libraries section of the Compiler Project Options

Native compiler and VisualCafé 1.x and Cafe 1.x
If the sj.exe from VisualCafé 1.x or Cafe 1.x is specified in the Windows system path before VisualCafé 3.1, an invalid flag error -link will result when using the native compiler. To avoid this error, make sure that the sj.exe from VisualCafé 3.1 is specified in the path first.

JDK 1.2 Native implementation
VisualCafé includes a new Win32 native Java implementation that is compatible with JDK 1.2.2 bytecode implementations. The new implementation is used when you target JDK 1.2 in the VisualCafé environment. JDK 1.1 is not supported in the new native implementation. Use the 'old' native compiler (sj11) if you have a compatibility issue or you do not want deprecation errors. Go to section III. Compiler for more information.

The native project templates support both native implementations and generated executables as specified in the Environment Options | Virtual Machine setting.

The native DLLs for this implementation are named: snj2*.dll, in order to distinguish them from the previous native implementation. The redistributable JDK DLLs included with VisualCafé Enterprise Edition 4.0 and any DLLs you produce for your applications must reside on the PATH, as is the usual case for Win32 DLLs. You must register the Win32 DLLs using snj2reg in order to use classes from these DLLs. With this new implementation you are not required to hard link libraries for each DLL into your native Java executable. The only library that will automatically be linked in is snj2.lib. Snj2.lib provides the core runtime support for your application. The redist installer, snj30rt.exe automatically registers the core runtime classes as well.

You can build JDK 1.2 native executables directly in the environment by setting Tools | Environment Options | Virtual Machines | Use VM: Java2 - JDK 1.2.2. You must also set your project type to Win32 Application.

To build a Native 1.2 executable from the command line enter the following:
> sj -obj <.java files and .class files> -link ExeName.exe -main <class containing main for the application>

Example:
> sj -obj foo.java bar.class -main baz.exe -main foo
Builds a Win32 native executable named baz.exe containing foo and bar. Execution starts at the main in class foo.

Building JDK 1.2 Native DLLs
Building and using a JDK 1.2 native DLLs requires two steps:

• Building the DLL
• Registering the DLL

Note: You must use snj2reg to register the DLL on any system that will be using it.

1. You can build JDK 1.2 native DLLs directly in the environment by setting the Tools | Environment Options | Virtual Machines | Use VM: Java2 - JDK 1.2.2. You must also set your project type to Win32 Dynamic Link Library.

Note: The DLL library name must start with the letters 'snj2' for the native runtime to automatically load it

2. To build a Native 1.2 DLL from the command line enter the following:
> sj -obj foo.java -link snj2foo.dll

3. Copy snj2foo.dll to c:\winnt\system32 or wherever your system32 directory is located

4. Register the DLL by using snj2reg as follows: >snj2reg c:\Winnt\system32\snj2foo.dll.

When snjrt30.exe is run a folder SNJ2HOME is installed in your system32 directory. It contains a Lib directory specifically for the new native implementation. This is where the native runtime looks for resource files e.g. *.properties files.

See the Online Help for more information.

Note: If you are switching native JDK 1.2 projects to JDK 1.1, manually add all the JDK 1.1 libraries to your project.

How to create a native dll if you do not have the source code
If you have a jar file called libutil.jar in d:\jars\lib that you want to use in a native application perform the following steps:
1. Create a new subdirectory in d:\jars\lib\libutil and change to the new directory.
2. Run the jar utility using: jar xvf ..\libutil.jar.
3. Pipe the output in the directory to an .rsp file using the command: dir *.* /s /b > files.rsp.
4. Edit files.rsp and change the absolute filenames to relative to the current directory. For example, change: d:\jars\lib\libutil\com\libutil\foo.class to com\libutil\foo.class.
5. Remove any empty directories in files.rsp and save the file.
6.Run sj -obj @files.rsp -link snj2libutil.dll
7. Copy snj2libutil.dll c:\winnt\system32\
8. Run snj2reg c:\winnt\system32\snj2libutil.dll

Your DLL is now ready for use in a native application.
Note: If the jar file references native methods in other DLLs, these DLLs must be copied to c:\winnt\system32 and renamed so that they begin with 'snj2'. Since
they were not created with sj then they do not need to be registered.

Executing JDK 1.2 Native files outside the VisualCafé development environment
Executing a JDK 1.2 Native executable outside of the VisualCafé development environment may result in the following error message when the executable contains database icons:

"Couldn't read button's icon"

The following steps provide a workaround:

1. In Windows NT, choose Start | Settings | Control Panel | System | Environment.
2. Select the CLASSPATH in the User Variables field to edit it.
3. Add <VisualCafe>\Bin\components\dbaw_awt.jar to the CLASSPATH.

Note: In Windows 95/98, edit the Autoexec.bat using Sysedit.exe and add <VisualCafe>\Bin\components\dbaw_awt.jar to the CLASSPATH.

Back

Top

V. Swing

Back

Top

VI. Deployment and JAR Tools

• It is recommended that you do not use the copy resources to output directory option if your source and archive output directory are in the same location. If you do this all resources will be overwritten with the same contents but the date will change; causing a potential problem with version control systems.
• Sun JAR signing must work on the command line before you can use it inside of VisualCafé.
• When signing a JAR file locally, the JAR file name created is appended with a .sig extension. For example, foo.jar.sig.
• When signing a JAR file via FTP, the JAR file name created is the same as in the Project Options. For example, foo.jar.
• The directory location for FTP is server dependent. You must know the appropriate syntax for each FTP server you will connect to.
• AutoJAR ignores the "Create Standalone Archive" option. All JARs created with AutoJAR contain only the files in the Project.
• All files in your Project that you include in an Archive must be on the system CLASSPATH for deployment to find them. If the files are not on the CLASSPATH, you will receive an error message.
• Classes dynamically loaded by the methods forName(), getResource(), and getBundle(), etc. do not show up as JAR entries; you must add them manually. If you add them to your project, then Deployment will be able to find them.
• There is a bug in the JDK that results in corrupt JAR entries being created in compressed JARs. If you get a Cannot Find File error message when creating a JAR, you may be able to fix it by uncompressing the JAR that you are getting the JAR from and re-JAR'ing it without compression.
• When creating a JAR from a project, you should not create a JAR that has the same name as a JAR that is referenced outside of your project. For example: If you are using a SpecialGrid in c:\SGRID.JAR from a third party vendor in your project, do not create a JAR with the name of c:\SGRID.JAR.
• Jar Viewer: The manifest display is limited to 32K of text. To view Manifest files that are larger than 32K, multi select (shift-click) the entries that are less than 32K, and add one at a time.
• When using signing for a JAR, the *.sig file name will be different than your *.jar file name. If you want them to use the same file name, manually rename your *.sig file.
• When delivering beans to a UNIX platform, the WebLogic Server will need to create and write to certain directories. For all beans, it needs to write to the weblogic.properties file and create directories under the 'classes' directory. For some beans, stateful beans, for example, it needs to create a 'pstore' directory for persistence storage. It tries to create this under the user's home directory. The read/write/execute rights of the user that started ddservices are the ones passed to the WebLogic Server. Therefore, the user who starts ddservices needs sufficient rights to carry out these tasks.

Browser Related Issues

Local

1. When you launch Microsoft Internet Explorer within the VisualCafé environment or when Internet Explorer executes an applet on a local machine, please be aware that Internet Explorer doesn't refresh its cache. You'll need to reboot your machine if you make any changes to your Java classes.
2. When you launch Internet Explorer within the VisualCafé environment, make sure that you have the class path of your machine set to:

   ..../symbeans.jar
   ..../java/lib/classes.zip

3. For local deployment with Internet Explorer, reset the directories in the Project Option tab to include the following files instead of using the default setting.:

java\lib\classes.zip
bin\components\symbeans.jar

Remote

1. If a Validation Adapter is configured to display a dialog box when the validation rule fails, the dialog box won't display in the case of a deployed AWT applet. Instead, the message displays in the Java Console because the dialog requires Swing classes.

To run applets in a JDK 1.2 environment, locally or remotely, use the following steps.

To set up the client side:
1. Download the Java plugin from http://java.sun.com/products/plugin/ . Install the Java plugin, following the instructions in the installer.
Note: Make sure you get JRE 1.2.2 or later.

Important: Remove any CLASSPATH entries that point to VisualCafé or its subdirectories. In Windows 95/98, edit the Autoexec.bat using Sysedit.exe. In Windows NT, choose Start | Settings | Control Panel | System | Environment. Select the CLASSPATH in the User Variables field to edit it.

To set up the server side:
To use the java plugin instead of the default VM of a web browser, you need to write some HTML code such as the following example:

<OBJECT
classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"width="506" height="291"
align="baseline"codebase="http://java.sun.com/products/plugin/1.2/jins tall-12-win32.cab#Version1,2,0,0"><PARAM NAME="code" VALUE="TestApp.class"><PARAM NAME="archive" VALUE="javx.jar"><PARAM NAME="type"
VALUE="application/x-java-applet;version=1.2"><COMMENT><EMBED type="application/x-java-applet;version=1.2" WIDTH=506 HEIGHT=291 code="TestApp.class"
archive="javx.jar"pluginspage="http://java.sun.com/products/plugin/1.2 /plugin-install.html"><NOEMBED></COMMENT>No JDK 1.2 support for APPLET!!</NOEMBED></EMBED></OBJECT>

The above code works for both Internet Explorer and Netscape Navigator and user will be prompted to download and install the Java plugin, if it is not installed.
Use the OBJECT tag in Internet Explorer and the EMBED tag in Netscape Navigator.

For more info on HTML tags refer to http://java.sun.com/products/plugin/1.2/docs/tags.html

Back

Top

VII. Revision History

Back

Top