1. the applet itself has restrictions: it cannot read/write the local file system or communicate with a third party, except for the server that provides the download of the applet.
2. After the applet is written, it cannot be published in HTML using the applet tag. You must use sun's htmlconverter tool to convert the applet tag into an object tag. For this reason, refer to the previous post.
3. Make full use of the Java console during applet debugging. The Java console is a very useful terminal that can be used to debug the applet. When you find that the Applet Class is not found, open the console and enter the L (lower-case l) command to print the current JRE Applet search path, you will find out where JRE has found it. In addition, after the jar or class file of the applet is changed, you can enter the X command in the console to clear the original cache and then reload the applet. In addition, the C (clear screen), V, T, and other common commands on the console can be used.
4. Due to struts, we may encounter some problems when loading the applet in JSP, especially for different browsers. These problems are actually one thing-can the browser find the Applet Class. In struts, an action triggers an action. After an action is processed, it is usually transferred to a JSP, which leads to inconsistent paths. If an action occurs, the page is displayed at/easycluster/JSP/cpuusage. JSP, but the address bar in the browser is http: // server: Port:/easycluster/cpuusage. EC ......, if the two paths are different, the applet cannot be found. The solution is: (1) write the <HTML: base/> tag in the JSP page (2) in IE. The codebase of the applet is http: // server: port/easycluster, so our archive should be written as JSP/cpuusageapplet. jar; but in Firefox, The codebase he is looking for is http: // server: Port/easycluster/JSP. Therefore, archive in JSP should be written as cpuusageapplet. jar, so we need to write a piece of JavaScript to determine the type of the browser, and then treat it separately
5. redraw the applet. When the applet redraws, it first calls the update method to clear the screen, and then calls the paint method to re-paint. There is a process of clearing the screen, so there will be flashes. In general, we can reload the UPDATE function, so that there will be no screen clearing process, to a certain extent, to avoid flickering. But remember to manually tune super. Paint (g) At the end, so that the interface is re-painted, otherwise there will be no screen after the applet comes out. In addition, for a static applet, we also suggest opening a thread to regularly refresh/re-paint the surface, because our applet is generally in an HTML, when HTML is rolled up or down or left or right, the image of the applet will be overwritten. If there is no regular re-painting mechanism, it will cause the applet to be overwritten and cannot be restored!
