So far my modification seems to work OK for me (with the applet). I only disable render1() for a very short time (usually less than 1 sec) so it doesn't seem to interfere. The only time I notice any problems is if the browser window gets resized while the render1 method is disabled.
I can't reproduce any strange behaviors for the application. I don't think it's a generally useful addition (beyond what you've already implemented as "set refreshing") so I'm fine keeping it local. Thanks. Dean On 2/14/07 2:44 AM, "Bob Hanson" <[EMAIL PROTECTED]> wrote: > I think you could have problems with this, but I'm not sure. some > commands do a repaint and wait for a message via the system update > indicating that the message has gone full-circle before they continue. > The update (paint?) event has to trigger to do that, and if you bypass > render1, then I think you break that cycle. The main reason the screen > is going black is that the frame renderer runs so that it sets certain > variables, like atom clickability, which can't be known until atoms are > rendered (or not) in relation to clipping planes. Also, the ZAP command, > which is inserted between models, runs clear(), which resets refreshing > to true, currently. > > But from the app, when I insert a logical trap there where you indicate, > strangely displays the console window text in the applet window (so I > see it twice) when I bypass render1. Maybe you know what's going on there? > > Bob ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
