All Projects | FPC | Lazarus: Packages, Patches | Lazarus CCR | Mantis | fpGUI

Main | My View | View Issues | Change Log | Roadmap | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0016008 [Lazarus] IDE minor always 2010-03-16 11:52 2010-03-16 17:15
Reporter Abou Al Montacir View Status public  
Assigned To Mattias Gaertner
Priority normal Resolution fixed  
Status resolved   Product Version
Summary 0016008: Help on RTL/FCL identifiers is brocken in Debian/Squeeze
Description Pressing F1 on any RTL/FCL identifier results in an error message "Help not found for identifier ...". Help on LCL continues to work. The issue seems to be related to the default configuration shipped in debian packages.

Debian installs FPC sources in /usr/share/fpcsrc/2.4.0 and installs Lazarus in /usr/lib/lazarus/0.9.28.2. It ships /etc/lazarus/helpoptions.xml and /etc/lazarus/environmentoptions.xml. We can read in the latest file <FPCSourceDirectory Value="/usr/share/fpcsrc/$(FPCVER)/">.

If this is changed to <FPCSourceDirectory Value="/usr/share/fpcsrc/2.4.0/"> the help system will work fine.
Additional Information Issue comes from FileItem.FileMatches(Filename) returns false inside the THelpDatabase.GetNodesForPascalContexts function. The FileName itself is good while the GetFullFilename inside THelpDBISourceFile.FileMatches gives <some path>/$(FPCVER) instead of <some path>/<fpc compiler version>.

The real issue comes from TIDEHelpDatabases.SubstituteMacros called inside the GetFullFilename function. It doesn't substitute the macro.

Looking deeper, TIDEHelpDatabases.SubstituteMacros gets the path as a macro $(FPCSrcDir) which itself get substituted to <some path>/$(FPCVER) but the substitution doesn't look recursive.

In fact TIDEHelpDatabases.SubstituteMacros is just a wrapper to IDEMacros.SubstituteMacros which resolves to TTransferMacroList.SubstituteStr. One solution would be to call DEMacros.SubstituteMacros in loop until all macros get substituted (recursive macros inclusion).

An other way is to let TTransferMacroList.SubstituteStr call itself on the content of a new macro before replacing it. This is cleaner, no?

One issue I have to investigate is that TTransferMacroList.SubstituteStr seems to have some recursive cases but I didn't manage yet to understand it.
Tags No tags attached.
Fixed in Revision
LazTarget -
Widgetset GTK 2
Attached Files

- Relationships

-  Notes
(0035642)
Vincent Snijders (manager)
2010-03-16 16:21

 Please test with r24035.
(0035643)
Abou Al Montacir (developer)
2010-03-16 17:08

 Now it is working, but I'm concerned of this function

function TIDEHelpDatabases.SubstituteMacros(var s: string): boolean;
begin
  Result:=IDEMacros.SubstituteMacros(s);
  DebugLn(['TIDEHelpDatabases.SubstituteMacros AAA1 ',s,' ',Result]);
  Result:=IDEMacros.SubstituteMacros(s);
  DebugLn(['TIDEHelpDatabases.SubstituteMacros AAA2 ',s,' ',Result]);
end;

Is it normal to call IDEMacros.SubstituteMacros(s) twice?
(0035645)
Mattias Gaertner (manager)
2010-03-16 17:15

 sorry. I forgot to clean up.

- Issue History
Date Modified Username Field Change
2010-03-16 11:52 Abou Al Montacir New Issue
2010-03-16 11:52 Abou Al Montacir LazTarget => -
2010-03-16 11:52 Abou Al Montacir Widgetset => GTK 2
2010-03-16 14:14 Abou Al Montacir Issue Monitored: Abou Al Montacir
2010-03-16 16:21 Vincent Snijders Note Added: 0035642
2010-03-16 16:21 Vincent Snijders Assigned To => Mattias Gaertner
2010-03-16 16:21 Vincent Snijders Status new => feedback
2010-03-16 17:08 Abou Al Montacir Note Added: 0035643
2010-03-16 17:09 Abou Al Montacir Status feedback => acknowledged
2010-03-16 17:15 Mattias Gaertner Note Added: 0035645
2010-03-16 17:15 Mattias Gaertner Status acknowledged => resolved
2010-03-16 17:15 Mattias Gaertner Resolution open => fixed

Main | My View | View Issues | Change Log | Roadmap | Docs
  
Mantis 1.1.1[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker