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

[Mike Bonner]

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 <bonnmike at gmail.com> 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 <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
>>
>