Robert Hanson wrote: > I'm so glad to see that the resizing does that. Yes, that's right -- > for now at least an error in rendering is not sent out in any other > way -- there could be hundreds of these as the applet continues to try > to repaint during resizing. Question: Did it go back to normal after > you resized it back to an acceptable value? Or was the end of the > show? > I forgot to mention it. After resizing back to 600x600 pixel everything seemed to be ok.
> For now, the scriptCallback is very specific and always reports any > error that occurred of any sort in its "termination" callback (with a > fourth parameter -- the execution time, provided the error was due to > a script command. It wasn't doing that earlier, and probably still > doesn't in Jmol 11.6, but it does in Jmol 11.7. The rendering errors > are different, and I propose we create an errorCallback method to > handle those. This should be reliable, because rendering errors almost > certainly involve too large a screen, and that buffer can be cleared > to provide more memory for the callback. An errorCallback option could > clearly distinguish between Java Errors, Java Exceptions (as in file > loading), and Jmol scripting errors. There will be no translation > problems there. > > >> The examples work well with Java 1.4.2_18 and Firefox 3.0.4 on Linux. > > great. > >> If I provoke an out-of-memory error by resizing the applet to 6000x6000 >> pixel >> (http://www.imb-jena.de/cgi-bin/3d_mapping.pl?CODE=1deh&JMOLVERSION=11.7.16_dev) >> Jmol traps the error but the message (see below) is only displayed in >> the java console and for example not in the messageCallback stream. >> >> ======= error message =========== >> viewer handling error condition: java.lang.OutOfMemoryError >> Error during rendering: java.lang.OutOfMemoryError >> ================================= > > > that's what I like to see! I'm a little surprised it didn't say the full > > java.lang.OutOfMemoryError: Java heap space > > but that's still what we need -- "OutOfMemoryError" will NOT be translated. > > >> I havn't found a resolution yet for the internationalization problem of >> all kinds of error messages: >> The messages sent by "messageCallback", "scriptCallback" and >> 'jmolGetPropertyAsString("errorMessage")' are translated. This makes >> writing a parser very difficult because it must understand all error >> messages in all languages. And it must be adapted to each new language >> added. > > I have a solution for you for that. The part "script ERROR:" is being > translated, but the part after that is not. In any case, it's not the That is not what I observe. The whole error message is translated for example to german. > message callback that you want for this -- it's the scriptCallback. > With that callback there is a numeric parameter that indicates script > starting (-2), script processing (0), script ending (-1), or script > terminated (milliSeconds n > 0). If it's a memory error the message > will will be present in the script termination callback and definitely > include "java.lang.OutOfMemoryError" in it. > Since I started to implement an error detection system for the Jena3D Jmol interface it is supposed to detect a larger number of errors, not just out-of-memory errors. Regards, Rolf ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Jmol-users mailing list Jmol-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-users
