Recent

Author Topic: Unit LazHelpHTML - HtmlBrowserHelpViewer1.BrowserParams := (?);  (Read 4308 times)

PaulANormanNZ

  • Full Member
  • ***
  • Posts: 115
Hi,

This question has been touched on, but not fully explored.

What are the possible entries please for:---

 HtmlBrowserHelpViewer1.BrowserParams

%s is the only one referenced any where I can find on the web.

Like others, what I want do is have things like ---

    html/index.html?do=fileActions
And
    html/index.html#fileActions

As commented elsewhere in this Forum, somewhere in the unit LazHelpHTML everything after index.html gets stripped out (or more precisely in ShowNode(..)   BrowserProcess (TProcessUTF8).execute

Here is the thing, taking %s out of BrowserParams changes nothing, putting it in appears to change nothing as well.

Both with and with out %s, the base web page html/index.html still opens, and everything after index.html is ignored.

It seems definite (done some showmessage()s ) that THTMLBrowserHelpViewer.ShowNode passes the correct information to  BrowserProcess (TProcessUTF8), BrowserProcess.CommandLine:=CommandLine;

But somewhere in  BrowserProcess.Execute;  <filename->?... and <filename->#... all get lost.

I can successfully run my expected result, from a non-Administrator command prompt

C:\Users\USER>"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"  file:///E:/Projects/Lazarus/People/Michael%20Too/DAZ%20type%20stuff/transfer%20assets/html/index.html?#fileActions

And the browser opens nicely at the bookmark.

I have tried openURL(Node.URL); and not surprisingly there are the same problems. (even when replacing spaces for %20 in Node.URL)

As a work around, I have disabled BrowserProcess.Execute in THTMLBrowserHelpViewer.ShowNode .

And on Windows have placed this call in THTMLBrowserHelpViewer.ShowNode towards the end.

Using the Windows specific  unit shellapi

 shellexecute(0, pchar('open'), pchar('C:\Program Files (x86)\Google\Chrome\Application\chrome.exe') ,pchar(stringreplace(Node.URL,' ','%20',[rfReplaceAll]) ),'',0);


I am also experimenting with the registry key HKEY_CURRENT_USER\Software\Classes\http\shell\open\command\(Default)
and like.

I realise the limitations of this, but on Windows, the default browser call used by Lazarus components/units utilises a url.dll which I think is the actual problem.

Lazarus' openUrl() does not actually locate the path to the browser binary directly, but relies on behind the scenes calls to registry entries? With the whole process trimming everything after the file extension.

If under Windows openUrl() in Lazarus actually itself got that browser binary path from registry, and did not rely on an indirect call, then all would be fine?

Other wise this process is actually being used:

C:\WINDOWS\system32\rundll32.exe url.dll,FileProtocolHandler %s

Any help from anyone familiar with this would be greatly appreciated please.

Paul

P.S. meanwhile I've stopped using the html help components and added the following to my project ..

function TprocessFiles.doHelp(Command: Word; Data: PtrInt; var CallHelp: Boolean
  ): Boolean;
var
  buildUrl : string;
   browserCommand: string='';
  Registry: TRegistry;
begin
  // http://wiki.freepascal.org/fcl-registry
  Registry := TRegistry.Create;
  try
    // Navigate to proper "directory":
    Registry.RootKey := HKEY_CURRENT_USER;
    if

Registry.OpenKeyReadOnly('\Software\Classes\ActivatableClasses\Package\DefaultBrowser_NOPUBLISHERID\Server\DefaultBrowserServer')
then

      browserCommand:=Registry.ReadString('ExePath') //; //read the value of the string
    else
     begin
       showmessage('registry Not Opening - trying for Chrome');
        browserCommand:='C:\Program Files (x86)\Google\Chrome\Application\chrome.exe';
     end;

  finally
    Registry.Free;
  end;

  // showmessage( browserCommand);

  callHelp := false;
  buildUrl :=  #34 + 'file://' + extractfilepath(application.ExeName)
               + 'html\index.html#'
               +  screen.ActiveControl.HelpKeyword
               + #34 ;

 shellexecute(0,
         pchar('open'),
         pchar(browserCommand) ,
         pchar(buildUrl ),'',0);


         // 'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe'
end;   
                     

And in my main form added to FormCreate()

 application.OnHelp:= @doHelp;

And set the HelpType to htKeyword
and HelpKeyword  to the bookmark or whatever I want.
« Last Edit: April 23, 2014, 09:08:48 am by PaulANormanNZ »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: Unit LazHelpHTML - HtmlBrowserHelpViewer1.BrowserParams := (?);
« Reply #1 on: April 24, 2014, 11:55:07 am »
This seems to indicate that on newer Windows versions (newer IE versions?), url.dll arguments must be quoted to retain anchor info:

http://stackoverflow.com/questions/300509/how-to-launch-a-file-protocol-url-with-an-anchor-from-java

If that helps, please file a bug.

PaulANormanNZ

  • Full Member
  • ***
  • Posts: 115
Re: Unit LazHelpHTML - HtmlBrowserHelpViewer1.BrowserParams := (?);
« Reply #2 on: April 25, 2014, 06:58:09 am »
Thanks marcov,

http://stackoverflow.com/questions/242579/limit-for-url-length-for-rundll32-url-dll-fileprotocolhandler and related posts certainly suggest possible workaround, but...

http://social.msdn.microsoft.com/Forums/ie/en-US/84db314c-2686-4499-a8c9-6a8ecfcf196d/ie7-local-html-files-and-parameters?forum=iewebdevelopment

... implies that the problem has been there for a great many years (2007 -  mid 2013). I had tried even completely encasing the whole argument in quotes, as shown in one Java example.

Its not so much a Lazarus (FP) bug, as Microsoft having moved the ground under people's feet :)

Would I report it as a new technique/approach being needed for Win OS (Registry reading for actual default browser - possibly Vista, 7, 8.1 difffernt keys)?

And would the solution lie in a revamped openUrl() rather than using the present Tprocess approach, and changing Help components to use openUrl()?

Paul

PaulANormanNZ

  • Full Member
  • ***
  • Posts: 115

 

TinyPortal © 2005-2018