Thanks Bob for the quick reply.
> Try
>
> x = jmolScriptWait('print getProperty("boundboxInfo")')
I didn't actually do a good job in explaining my setup completely in the
previous post, mainly because I didn't know too much about how javascripts work
before. Some education over the weekend helped me pinning the problem down a
bit better, I think. So here's the whole story:
I have an applet that loads the user's structure when they hit a button
(onclick=loadFunction()). And as part of the loading commands, I set
boundbox{all} on. Then after the the loading process, I want to get back the
current boundboxInfo by using the getProperty() function.
What I didn't know was the threading business in javascript, and that the
loading and getProperty() functions do not necessarily take place in
sequential order, but rather asynchronously and simultanously. So what I ended
up with was that the getProperty() function returned before the loading
finished, which explains why by setting a timeout (or using alert) on the
getProperty function often restored the correct order. Here's the snippet of
the relevent codes:
---
<input value="display my target" id="display"
onclick="display(structure)" type="button">
function display(structure) {
jmolScript("load "+ structure+"; boundbox{all} on;");
//alert("equivalent of timeout"); //with this in, it works
var x = jmolScript('print getProperty("boundBoxInfo")');
alert(x);
}
---
With the "timeout" alert commented out, x returns the default center{0,0,0}
vector{10,10,10}, because getProperty returns before load finishes. However, on
subsequent button clicks, x returns the right values. With the "timeout" alert
uncommented, x returns the right center and vector engulfing the molecule.
So logically I should enforce a sequential execution order for loading and
getproperty. I tried to use jmolScriptWait on load, as well as getProperty,
however it froze up the browser (firefox 2.0.0.14 on mac). I'd found out from
various sources including some of the past posts on this list, that it is
likely because the onclick itself is an eventlisterner, so jmolscriptwait hangs
because it hasn't been started as a new thread. Because I don't know how to
explicitly start a new thread, I'd put:
onclick="setTimeout('display(structure)', 0);" to the button input, that didn't
help.
I am hoping this is an obvious mistake that's easy to correct. Any suggestions?
Thanks you in advance.
> -- btw -- you really should be using jmolScript, not applet.script --
> some reason for doing that?
Ignorance. I didn't think I need the fancy interface that some of these other
jmol demonstration pages showed. And since the doc said: "Please, note that
these methods do not use the JavaScript library, which is the
currently recommended method to start scripting JmolApplet.", I decided
that directly manipulating applet was best suited for what I want to do. I
actually didn't know why scripting without using the javascript library (which
I take it to mean Jmol.js) is the recommended method.
-Rob
_________________________________________________________________
If you like crossword puzzles, then you'll love Flexicon, a game which combines
four overlapping crossword puzzles into one!
http://g.msn.ca/ca55/208-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
