Re: [Jmol-users] getProperty out of sync

[Bob H. <ha...@st...>]

I was thinking about this a little more. The standard solution to this 
problem is to set up a callback. You can do this very simply just be using

    set messageCallback "somefunctionname"

and then at the end of your script, or whenever you want to be sure you 
are synchronized, just have in your script at that point

  echo APPLET_DONE

When the callback comes, your callback method does the boundbox call, 
and everything is synched.

The function will be called with parameter 1 being the name of the 
applet object and 2 being the message.

OR, better, you can do it in one go -- just have the echo something like 
this:

 refresh; echo  @{"The Boundbox is now " + getproperty("boundboxInfo")}

The @{} construct allows building of the parameter on the fly. In this 
way you get the message you need when you need it. No threading issues. 
I don't know if the refresh is needed -- try with and without. The point 
is that callbacks have proven to be very reliable, and since you design 
your own message, that's really about all one needs.

By the way, Jmol is protected against synchronization issues -- you can 
send as many commands at it as you like, and they will be processed in 
order -- EXCEPT for this particular 
getPropertyAsArray/getPropertyAsString business. Callbacks are 
definitely the solution.



rob yang wrote:

> 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
>
> ------------------------------------------------------------------------
>
>------------------------------------------------------------------------
>
>-------------------------------------------------------------------------
>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
>Jmo...@li...
>https://lists.sourceforge.net/lists/listinfo/jmol-users
>  
>


-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get. 

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900