eric capps wrote:
>it occurs to me, are we going to need to update bonds when this
>happens? i know very little about chemistry so i'm not too sure how
>this all works.
>
>so i've mucked around with everything a bit, and it seems to refresh
>coordinates rather well. one issue i've noticed is that i often have
>to move the model after i call the javascript method to actually
>display the changes. in fact, with the build i've made of your branch
>(what seems to be the latest), this same problem occurs in your
>setAtomCoord method. any ideas?
>
>
>
you need to invoke Viewer.refresh() manually using
jmolGetPropertyAsJavaObject("jmolViewer").refresh()
Or you can just use
jmolScriptWait("")
because a script automatically refreshes at the end.
re: testing applet code:
is there an easy way to debug the applet in a web context? i know
that within eclipse you can launch it and set breakpoints and
everything, but i'd like to be able to see how it responds to
commands from Jmol.js without having to rebuild the jar everytime and
be unable to set breakpoints.
failing the ability to do this within eclipse, what other avenues can
i take? is there, for example, an easy way to pass debugging
information to the jmol console?
--My method is decidely low tech and not necessarily to be recommended if
someone else has a smarter approach:
1) I use Build.xml within Eclipse, including "clean" reordered before "main" if
I've messed with JmolConstants or did anything that might affect any interface
or just before an upload. This creates the Jar files in the main workspace
directory.
2) I use the test HTML files you see in
http://www.stolaf.edu/people/hansonr/jmol/test/proto to test all applet code.
The idea here is to document all tests in relation to any particular topic so
that I can run through them all quickly. I often find where I've broken one
thing to fix another this way.
3) I have a little DOS batch file that copies the JAR files from the Eclipse
workspace to my working HTML directory. I always call it "t.bat".
So I do the build, and when I see "BUILD SUCCESSFUL" I exit the browser
(otherwise any new JAR file is not loaded), switch to DOS, type "t", and I'm
testing.
Generous use of
System.out.println(...)
gives me the feedback I need. Also, the following script commands are useful:
set debugScript
set testFlag1
set testFlag2
set testFlag3
set testFlag4
Those test flags you can check using viewer.getTestFlag1(), ...2(), etc., so
you can test different options if you want to.
I realize this is back to the "no breakpoint" methods of yesteryear, but it
works for me, and the HTML files I use for testing allow for very quick
retesting of scripts, and also end up being demonstration pages, so I figure
that makes up for the nuisance of no breakpoints.
Bob
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
