Followup, it will actually start with currenturl# I believe, so that should be what is checked for. Am I correct in my understanding that the page itself is not reloaded on link hrefs that begin with #? If so, should still work fine this way, will have to setup a full blown page and see how it behaves.
On Tue, Aug 10, 2010 at 3:39 AM, Mike Bonner <[email protected]> wrote: > Think there might be an easier way to do this, have only done a little > experimentation though. > > If your page has links in the form of <a > href=#?yourparam=something&yourotherparam=somethingelse&thefinalurltogoto=www.myurl.net>The > Link Text</a> > Then when its clicked by default it will go nowhere, yet you can pass > in any combination of information you wish, process it then if desired > navigate to whatever page you want under those circumstances. > > I had been thinking that the advanced callback messages could be > turned on in windows but it would still require either a browser stop, > or setting the href to # so that no navigation occured before the > element ID could be checked, then do it different with osx. Using > this alternate method it should work the same way on both platforms. > Click, check the url in browserbeforenagivate, if it starts with #, > bingo bango bongo, process it and move along. > > On Tue, Aug 10, 2010 at 1:44 AM, Ben Rubinstein <[email protected]> wrote: >> 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 >> > _______________________________________________ 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
