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

[Terry Judd]

Thanks Andre, that sounds very promising. I'll give it a whirl.

Terry...


On 9/08/10 10:55 PM, "Andre Garzia" <andre at andregarzia.com> wrote:

> Terry,
> 
> 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.
> 
> Andre
> 
> On Mon, Aug 9, 2010 at 1:47 AM, Terry Judd <tsj at unimelb.edu.au> wrote:
> 
>> What's really annoying is that you used to be able to grab data from form
>> elements using browserBeforeNavigate - the values of the form elements
>> would
>> be reported in the url variable, even if no action was ascribed to the
>> form.
>> This was really useful as you could use a webform to capture some user
>> entered data, intercept it with browserBeforeNavigate, process and/or store
>> it in Rev and then do some other stuff - in some cases removing the need
>> for
>> server-side logic or cookies (for example, I used it to store and retrieve
>> student's quiz answers submitted during a session).
>> 
>> This still works in OSX (you just have to parse some 'garbage' off the
>> front
>> of the URL) but broke in one of the earlier versions of the revBrowser
>> externals for Windows. AFAIA, it still works with the original altBrowser
>> external.
>> 
>> I reported this some time ago (more than 3 years) but it was never fixed
>> and
>> my original bug report has disappeared. I for one would like to see this
>> feature reinstated.
>> 
>> Anyone else?
>> 
>> 
>> On 8/08/10 9:50 AM, "Andre Garzia" <andre at andregarzia.com> wrote:
>> 
>>> Folks,
>>> 
>>> Sometimes do you want to create some fancy interface using RevBrowser and
>>> want to communicate back with the stack that hosts the RevBrowsr view.
>> One
>>> quick way of doing this is to use custom protocols (so that you know that
>>> url is yours) such as:
>>> 
>>>   myapp:refreshGui
>>>   myapp:executeHandler/doStuff
>>> 
>>> For example, some construct like:
>>> 
>>>   <a href="myapp:refreshGui">Click here to Refresh GUI</a>
>>> 
>>> When that link is clicked, you could use a browserBeforeNavigate handler
>>> such as this one:
>>> 
>>>   on browserBeforeNavigate pID, pURL
>>>     set the itemdel to ":"
>>>     if word 1 of pURL is "myapp" then
>>>       -- our protocol!
>>>       switch word 2 of pURL
>>>         case "refreshGui"
>>>           refreshGui
>>>           break
>>>       end switch
>>>     put true into browserCancel
>>>     end if
>>>   end browserBeforeNavigate
>>> 
>>> 
>>> This of course works great on Mac OS X and you can create your own
>> browser
>>> windows that trigger things back with no problem and you don't mix
>>> http://or other protocols with your own, very elegant.
>>> 
>>> Now on Windows land (damn you Redmond!!!) things are different. It
>> appears
>>> that browserBeforeNavigate is only triggered afted IE renderer inspects
>> the
>>> URL. When it finds out a custom protocol, it checks to know if the system
>>> can handle it. If you are using your own and haven't fiddled with Windows
>>> Registry to register it, that check will fail and IE will change the damn
>>> URL for you pointing to a internal windows dll page showing something
>> like:
>>> "Hey Fella, I don't know how to handle this!" which of course is an
>> exercise
>>> in patience since my own browserBeforeNavigate will prevent IE from even
>>> trying to handle my own protocol.
>>> 
>>> This is not a RevBrowser BUG per se since RevBrowser is not doing
>> anything,
>>> it is IE again in its infinite wisdom trying to do things for you (which
>> it
>>> shouldn't). The only solution in these case is to add lots of Registry
>>> information, registering your own protocol, which will probably make
>> windows
>>> try to relaunch your standalone for every of those links.
>>> 
>>> Damn, microsoft always makes my life harder!
>>> 
>>> Andre
>>> 
>>> 
>>> 
>> 
>> --
>> Dr Terry Judd | Senior Lecturer in Medical Education
>> Medical Education Unit
>> Melbourne Medical School
>> The University of Melbourne
>> 
>> 
>> _______________________________________________
>> 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
>> 
> 
> 

--
Dr Terry Judd | Senior Lecturer in Medical Education
Medical Education Unit
Melbourne Medical School
The University of Melbourne