Bug Busters

[BigChimp]

Well, the themes stuff may be a clue. I dialled down all the graphics I could in an effort to make my Windows 7 look like Windows 2000 (Windows classic theme here)

[Mike.Cornflake]

Well, I can fix the problem in the lHelp project.  Doubt my solution is the correct one, but I'll post it here on the offchance someone known something about IPCServers.

If I disable the IPCServer Timer before calling the FileOpen dialog (and reenable it afterwards), the problem goes away.

I doubt this is the fully correct solution (though I think this should be done anyway), as to me it implies a larger problem with that timer code in procedure THelpForm.ServerMessage(Sender: TObject);...

Code: [Select]

procedure THelpForm.FileMenuOpenItemClick(Sender: TObject);
Var
  bState : Boolean;
begin
  // New code
  If assigned(fServerTimer) Then   
  begin
    bState := fServerTimer.Enabled;
    fServerTimer.Enabled := False;
  end;
  Try

    //Existing code
    if OpenDialog1.Execute then
    begin
      if OpenURL('file://'+OpenDialog1.FileName) = Ord(srSuccess) then
        AddRecentFile('file://'+OpenDialog1.FileName);
      RefreshState;
    end;

  //New code
  finally
    If assigned(fServerTimer) Then
    begin
      fServerTimer.Enabled := bState;
    end;
  end;
end;
UPDATE:  Wierd.  The bulk of the code in .ServerMessage is not being called. 

Code: [Select]

procedure THelpForm.ServerMessage(Sender: TObject);
var
  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
    Stream := fInputIPC.MsgData;   //  <--- Breakpoint set here never gets called
    Stream.Position := 0;
    FillByte(FileReq{%H-},SizeOf(FileReq),0);
    Stream.Read(FileReq, SizeOf(FileReq));   
So it's .PeekMessages that causing the problems?   I think I'm approaching my limit of usefullness here :-(

UPDATE2:  No, I'm not at the limit of my usefullness.  That first parameter to PeekMessage is a TimeOut.  Bet it's in seconds, and a 5 second delay in the UI every 200ms is consistent with the responsiveness of the OpenFile dialog.   Why it only happens on themes is wierd...  (unless Classic Theme blocks the application process queue, but the modern allows it??)

[ChrisF]

Nice idea, but I've now confirmed that the issue reproduces regardless of either the optimisation level set at the project level (Clean up and Build each time), or with Lazarus rebuilt with different optimisation levels :-(

Yes, I've also done some tests with various optimizations and the result is also always the same for me (i.e. working properly).

As you've suggested, I've also tried with or without themes but there are no differences for me. However, my tests were made on Windows XP, and themes for Windows XP are not as complex as for Vista or above.

Looking at the bug report, it seems that people who have this bug are using Win7/Win8 (at least Vista or above). Of course, it could be only a coincidence, but it also might be related to themes only for the recent versions of Windows (i.e. Vista+).

Sorry, I'm afraid I can't help any more... :-(

[Mike.Cornflake]

As you've suggested, I've also tried with or without themes but there are no differences for me. However, my tests were made on Windows XP, and themes for Windows XP are not as complex as for Vista or above.

Exactly correct.  Inside Win32WSDialogs there's a specific switch in the OPenDialog code that only calls the new openDialog if OS>=Vista or themes enabled.   I only concentrated on the Themes part, but yes, Operating System would also account for why this happens for some people, but not others...

Sorry, I'm afraid I can't help any more... :-(

This has been a learning curve for me, and your help has been much appreciated - so thanks    (But yeah, I also feel like I'm running out steam...)

[BigChimp]

Well, I can fix the problem in the lHelp project.  Doubt my solution is the correct one, but I'll post it here on the offchance someone known something about IPCServers.

Well.... I'm learning. Let's put it that way.

Thanks a lot for going through that, I'll definitely have a look.

I'll assign the bug to me and get back to you guys in this thread if/when I need more help... (e.g. testing with a new version of trunk or a patch against 1.2.4)

Thanks everyone!

[Mike.Cornflake]

I'll assign the bug to me and get back to you guys in this thread if/when I need more help... (e.g. testing with a new version of trunk or a patch against 1.2.4)

Thanks everyone!

It's been a pleasure    

Don't know if you saw my two updates in that post above, but as well as disabling the timer, I'm also thinking the timer interval should be increased &/or the IPC timeout reduced.   If that timeout is in seconds (and it feels like it is), then a 5 second time out being called every 200ms is going to be problematic...

[BigChimp]

Yes, thanks, I'll have a look!

[JuhaManninen]

Unfortunately a patch has been ignored for long and now creates merge conflicts when I try to apply it.
Someone who likes detective work, please see where the code chunks were meant to go and create a new patch.
After that we can test if it solves the problem. If it does then we must think what to do with the ugly global variable.
The issue:
 http://bugs.freepascal.org/view.php?id=13397

[BigChimp]

PLEASE TEST!

Hi guys,
I've pushed Mike's fix to the code. Could you test again, please?
Thanks.

If I disable the IPCServer Timer before calling the FileOpen dialog (and reenable it afterwards), the problem goes away.

Strange. The IPCServer timer is presumably there to periodically peek at incoming messages from the IDE.
That Timer interval is in milliseconds...

Disabling it would disable listening to messages from the IDE while opening the file.... which would currently cause error messages in the IDE (such as "lhelp is not responding" or something) which is actually fine because it is busy doing something else [1]
... so I did as you proposed (commit 46286; cosmetic changes in earlier commits)

UPDATE:  Wierd.  The bulk of the code in .ServerMessage is not being called. 

Code: [Select]

procedure THelpForm.ServerMessage(Sender: TObject);
var
  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
    Stream := fInputIPC.MsgData;   //  <--- Breakpoint set here never gets called
    Stream.Position := 0;
    FillByte(FileReq{%H-},SizeOf(FileReq),0);
    Stream.Read(FileReq, SizeOf(FileReq));   
So it's .PeekMessages that causing the problems?   I think I'm approaching my limit of usefullness here :-(

UPDATE2:  No, I'm not at the limit of my usefullness.  That first parameter to PeekMessage is a TimeOut.  Bet it's in seconds, and a 5 second delay in the UI every 200ms is consistent with the responsiveness of the OpenFile dialog.   Why it only happens on themes is wierd...  (unless Classic Theme blocks the application process queue, but the modern allows it??)

The PeekMessage Timeout is milliseconds according to the help hint displayed on my Windows Lazarus. So that wouldn't be strange.

Additionally, if you're opening a file within lhelp you're presumably not at the same time telling the IDE to start context sensitive help etc so you wouldn't actually expect a message coming from the IDE.... so PeekMessage would just return false (which is why your breakpoint isn't hit).

(Having run lhelp with debugging output enabled, it seems the peekmessage timeout is actually fine, at least on my system - it catches all messages the IDE sends it.)

[1] Perhaps this entire stuff should be moved to another thread.... something I've only run away from in horror up to now...

Thanks a lot!

[Mike.Cornflake]

Unfortunately a patch has been ignored for long and now creates merge conflicts when I try to apply it.
Someone who likes detective work, please see where the code chunks were meant to go and create a new patch.
After that we can test if it solves the problem. If it does then we must think what to do with the ugly global variable.
The issue:
 http://bugs.freepascal.org/view.php?id=13397

I'll have a look at this today....

PLEASE TEST!

Hi guys,
I've pushed Mike's fix to the code. Could you test again, please?
Thanks.

I'll be checking to see if Git works for me out here.  If it does, I'll test.

Additionally, if you're opening a file within lhelp you're presumably not at the same time telling the IDE to start context sensitive help etc so you wouldn't actually expect a message coming from the IDE.... so PeekMessage would just return false (which is why your breakpoint isn't hit).

Valid comments.   My concern was not really that the breakpoint wasn't being hit, just that the only command being run was the peekmessages, and I couldn't work out why simple command was causing the OPenDialog issues.

[1] Perhaps this entire stuff should be moved to another thread.... something I've only run away from in horror up to now...

Too late :-)  Also, this isn't really the type of topic others will be searching for help in - and finally, I suspect we're near end game on this issue anyhow :-)

[BigChimp]

My concern was not really that the breakpoint wasn't being hit, just that the only command being run was the peekmessages, and I couldn't work out why simple command was causing the OPenDialog issues.

Agreed. I don't understand why that should matter, either.

[1] Perhaps this entire stuff should be moved to another thread.... something I've only run away from in horror up to now...

Too late :-)  Also, this isn't really the type of topic others will be searching for help in - and finally, I suspect we're near end game on this issue anyhow :-)

Mmmm, yes, but I just committed another workaround for issue
http://bugs.freepascal.org/view.php?id=26697
basically ignoring timeouts (reverting to an earlier state of affairs actually)... so the architecture isn't as it should be I suppose (or I'm not qualitifed to implement it correctly )

However, lhelp has been working for ages since before I started fiddling with it so leaving it would be quite a valid option....
OT:
The only things I'd like to see are:

• A nice way to show an hourglass cursor when invoking context-sensitive help for the firs ttime... that shouldn't last as long as all possible IDE sending timeouts though
• Improved searching/browsing in the chms itself - including the removal of the duplicate entry for LCL keywords such as TForm. Will require work at the fpdoc end, or if we're lucky, at the lazdoc whatever tool that calls fpdoc, I suppose

[marcov]

Btw, the bug I hate the most is that with anchordocking* pkgs, the tool palette suddenly scales to a huge height, and resizing it only lasts till next restart.

This problem is consistent on both *nix and windows. http://www.stack.nl/~marcov/ide_bad.png

[Mike.Cornflake]

Btw, the bug I hate the most is that with anchordocking* pkgs, the tool palette suddenly scales to a huge height, and resizing it only lasts till next restart.

This problem is consistent on both *nix and windows. http://www.stack.nl/~marcov/ide_bad.png

Couple of points.
1. This is a thread looking for volunteers to help close items in Mantis, so I'm glad to see you've joined :-)
2.  I've looked through Mantis, and while there are a uncomfortably large amount of AnchorDocking related issues, I simply cannot find one for the one you're talking about here.

[marcov]

1. This is a thread looking for volunteers to help close items in Mantis, so I'm glad to see you've joined :-)

I'm trying to assist Reinier with the lhelp issues, so I've already been drafted :-)

2.  I've looked through Mantis, and while there are a uncomfortably large amount of AnchorDocking related issues, I simply cannot find one for the one you're talking about here.

That is pretty much the reaction I hoped for. I didn't know what to look for, other than walking each and every report. Anyway, if it isn't known, I'll report it. I'm somewhat surprised since it is quite old (happens for half an year at least, if not an year).

[rvk]

That is pretty much the reaction I hoped for. I didn't know what to look for, other than walking each and every report. Anyway, if it isn't known, I'll report it. I'm somewhat surprised since it is quite old (happens for half an year at least, if not an year).

Do you happen to have a multi-monitor setup? There are a couple of reports in the bugtracker about not retaining the layout after choosing Save as default and restarting Lazarus.
I'm also on a multi-monitor setup but have Lazarus on my first monitor and although the initial layout is messed up, also in a report, when choosing my layout and saving it as default it pretty much stays the same after a restart. If i try to save default layout on my second monitor after restarting Lazarus it is also messed up.

Related bugreports:
http://bugs.freepascal.org/view.php?id=19810
http://bugs.freepascal.org/view.php?id=26646 (duplicate of 19810?)
http://bugs.freepascal.org/view.php?id=18298