NineChime forum

I mean saying yes when the applet asks to save layers file. Don't know if it's happening to everyone on my board. It doesn't work for me, and one other person mentioned it so far.

Well, this is what happens now. You can go in and re-touch, but when you send it again, and choose yes for saving .chi file, it puts the newly re-touched image into "recover pics" and gives it a new number. The first image still appears on the board, without the retouches. If you send with the "no" option for saving .chi file, retouches appear, but then layers are merged.

Last edited by acwitness (08-11-2008 17:44:05)

Thanks - applied the patch. Unfortunately I can't test it now because I'm back to getting java errors when trying to use the applet. I had changed servers and it was working ok for a couple of weeks for everyone, but then a few days ago a couple people mentioned that it stopped working for them again - and this morning it is no longer working for me. So frustrating - this is the error message:

Java Plug-in 1.6.0_07
Using JRE version 1.6.0_07 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\DEBRA
----------------------------------------------------
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
l:   dump classloader list
m:   print memory usage
o:   trigger logging
p:   reload proxy configuration
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
v:   dump thread stack
x:   clear classloader cache
0-5: set trace level to <n>
----------------------------------------------------
Exception in thread "AWT-EventQueue-6" java.lang.ClassFormatError: Incompatible magic value 1011373133 in class file cello/tablet/JTablet
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(Unknown Source)
    at java.security.SecureClassLoader.defineClass(Unknown Source)
    at sun.applet.AppletClassLoader.findClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.applet.AppletClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClassInternal(Unknown Source)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Unknown Source)
    at chibipaint.util.d.<init>(Unknown Source)
    at chibipaint.util.d.a(Unknown Source)
    at chibipaint.gui.J.mouseMoved(Unknown Source)
    at java.awt.Component.processMouseMotionEvent(Unknown Source)
    at javax.swing.JComponent.processMouseMotionEvent(Unknown Source)
    at java.awt.Component.processEvent(Unknown Source)
    at java.awt.Container.processEvent(Unknown Source)
    at java.awt.Component.dispatchEventImpl(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
    at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
    at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.run(Unknown Source)

Hi Waccoon - thanks for the response. Actually it turns out that this issue wasn't about Java at all. I posted at the ChibiPaint forum and got this response:


This problem has been reported to me before and I've now figured out the cause.

The reason the problem happens on your server and not on this site for example, is the way it handles 404 errors (what happens when pages are not found).

Here's what happens:

* ChibiPaint tries to load the JTablet class to handle the tablet pressure

* For applets, Java always tries to find the class on the server first, so it will try to get http://www.yourserver/chibipaint/cello/ … blet.class for example, which is where it expects to find JTablet.

* Normally most servers generate a 404 error for unknown urls, when that happens Java tries to find JTablet locally, and ChibiPaint is happy whether or not it finds it. But in your case, the server returns a normal page without the 404 error code and Java thinks it's the JTablet class. But it's not really the class file, it's a html page, so there is an unexpected error when that happens.

Then ChibiPaint keeps trying to load JTablet again and again so it becomes very slow.

To solve this problem and allow your users to have the tablet pressure if they have JTablet installed, you need to make sure that your server returns a 404 error when Java tries that url above. You can probably configure your server so that you can keep the 404 special page for the rest of the site.

I'll make modifications to ChibiPaint so that it's more robust and just reverts to normal functioning without tablet pressure if that error happens but I'm not sure I can modify it in such a way that JTablet will work on servers without 404 errors. So I definitely recommend that you modify that on your side.



It was my .htaccess/custom 404 page that was messing it up - happy to report that all is working well now!!

Well, funny you should ask that. I hadn't given a whole lot of thought to the actual content of the htaccess file, as it always seemed to work ok.

It looked like this:

ErrorDocument 404 http://acwitness.org/oekaki/404.shtml

I guess having the full path is a problem???

I changed it to

ErrorDocument 404 /404.shtml

and now it is working ok. Jeesh, I feel dumb!!