[ANNOYANCE] Custom protocols that are not registered do not trigger browserBeforeNavigate correctly on windows.

[Mike Bonner]

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 <benr_mc at cogapp.com> 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
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>