Thanks Andre, that sounds very promising. I'll give it a whirl. Terry...
On 9/08/10 10:55 PM, "Andre Garzia" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 >> [email protected] >> 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 _______________________________________________ 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
