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

[Andre Garzia]

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
>



-- 
http://www.andregarzia.com All We Do Is Code.