Hi list,

I'm getting a lot of errors trying to get context-sensitive help with lhelp. (in my patched copy of Lazarus; see second patch in http://bugs.freepascal.org/view.php?id=24743)
Lhelp will start up but give "Cannot handle this type of subcontent: "file://" for url: file://
It looks like the actual file name of the chm file is not being received by lhelp.

Normally I would always blame the compiler and/or RTL/FCL for my own or other people's incorrect code ;) but I'm starting to suspect recent fixes in simpleipc may have messed things up.

I'm going to have a look at that but first wanted to know whether other people with the config listed in the subject have the same issues (or whether it's PEBKAC/machine dependent).

Alternatively, review and correction of the patch in http://bugs.freepascal.org/view.php?id=24743
would be very welcome, too ;)

Finally, I would be grateful if somebody could indicate if my patch works for FPC trunk+Lazarus trunk?

Thanks,
Reinier

No interest? Not even when I mention fascinating keywords [1] Unicode, UTF-8, precision timer, clock, epiktimer, non-GUI event loop ;)

[1] that happen to be irrelevant concerning this subject though... I hope.

Reinier Olislagers wrote

No interest? Not even when I mention fascinating keywords [1] Unicode, UTF-8, precision timer, clock, epiktimer, non-GUI event loop ;)

ROFL

Regards,
- Graeme -

Reinier Olislagers wrote

No interest?

"Windows" is a show stopper keyword for me ;-)

-Michael

Reinier Olislagers wrote

Normally I would always blame the compiler and/or RTL/FCL for my own or other people's incorrect code ;) but I'm starting to suspect recent fixes in simpleipc may have messed things up.

Yes, Marco found out it is indeed FPC r27762 , see bug http://bugs.freepascal.org/view.php?id=26007

Confirmed that reverting that restores proper help behaviour; my patch then works as it should.

Thanks for the help, Marco!

Can you please explain what goes wrong ?
The bug report doesn't say what goes wrong.
'regression' is nothing I can work with...

The problem can well be that lhelp needs to be adapted. I tested the patch, and in all situations I tested, it worked correctly.

So, maybe it is another case of messages getting lost in windows, just as in the debug server. I'd like to establish that...

Michael.

Michael Van Canneyt wrote

On Mon, 28 Jul 2014, Reinier Olislagers wrote: > On 22/07/2014 08:51, Reinier Olislagers wrote: The problem can well be that lhelp needs to be adapted.

Yes, as I said, I agree with that.

In \components\chmhelp\lhelp\lhelpcore.pas (patched with [1] but shouldn't really matter), if I do
uses
...lazloggerbase, lazlogger...

procedure THelpForm.ServerMessage(Sender: TObject);
var
  BytesRead: LongInt;
  UrlReq: TUrlRequest;
  FileReq: TFileRequest;
  ConReq: TContextRequest;
  MiscReq: TMiscRequest;
  MustClose: boolean=false;
  Stream: TStream;
  Res: LongWord;
  Url: String='';
begin
  if fInputIPC.PeekMessage(5, True) then begin
    Res := Ord(srError); //fail by default
    Stream := fInputIPC.MsgData;
    Stream.Position := 0;
    FillByte(FileReq{%H-},SizeOf(FileReq),0);
    BytesRead := Stream.Read(FileReq, SizeOf(FileReq));
    if BytesRead<SizeOf(FileReq) then
    begin
      debugln('lhelpcore error: expected at least
filereq('+inttostr(SizeOf(FileReq))+' bytes); got '+inttostr(BytesRead));
      exit;
    end;
    case FileReq.RequestType of
      rtFile    : begin
                    Url := 'file://'+FileReq.FileName;
                    Res := OpenURL(URL);
                    debugln('lhelpcore: got rtfile, filename
'+filereq.filename);
                  end;

the log shows
lhelpcore error: expected at least filereq(520 bytes); got 0 so seems like an empty message.

HTH,
Reinier

Do we have somewhere working example code to look at and to compare with this lhelp code?

Juha

Juha Manninen wrote

Do we have somewhere working example code to look at and to compare with this lhelp code?

DebugServer and the examples in fcl-base/examples (these latter must be moved): ipcserver, ipcclient.

I tested using the latter.

Michael.