On 09/08/2010 13:55, Andre Garzia wrote:
I believe that this can be "fixed" by using client side javascript only. By
fixed I mean "restore that behaviour". If you specify an action that is a
javascript function and in that function you assemble your parameters in a
url and set the window.location of the running page, it should trigger
browserBeforeNavigate with the URL from the js function and your parameters
there. This should work on both windows and mac os x and it is quite an
elegant solution.
Bear in mind that while this works if you genuinely want the browser to
display a new URL (you just want to do stuff first), it is limited as a means
of calling back to Rev in general (but it is AFAIK the only way to do so).
In effect (from memory, syntax may be dodgy) you can have a javascript
function like this:
function tellRev (tMessage)
{
window.location = "SPECIALREV:" + tMessage;
}
tellRev("beep");
tellRev("show-onscreen-keyboard");
....etc
A browserBeforeNavigate handler can then catch the URL, spot the special
'protocol' prefix, do something with the rest of the so-called URL, and tell
the browser to cancel the navigation.
This works up to a point: the issue, at least on Mac OS X, is that when
javascript executes two statements to set window.location in succession, as in
the above example, one cancels the other. So if for example you have two
controls on the web page, each of which instructs Rev to do something, if the
user clicks both in quick succession, only one will execute.
See
http://quality.runrev.com/qacenter/show_bug.cgi?id=6986
for a proposed solution (which I admit I don't know if it's possible).
Ben
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
