We are porting our app to Delphi XE2 from Delphi 6. Problem is, the help file will not display no matter what I try.
Using Delphi XE2 (Update 3) on Win 7 64.
Using a valid help file (.chm) that works with my Delphi 6-built app.
I create a simple app with one button that calls help thusly:
Application.HelpFile := 'Help.chm';
if Application.HelpFile <> '' then begin
Application.HelpContext(0);
end;
I have HTMLHelpViewer in my uses clause.
The help file is in the same directory as the app. When I click on the button the help file is not displayed! I see nothing. No errors.
I tried several different help files, all of which are valid and I can open via Explorer.
I also tried calling the table of contents directly like this:
HtmlHelp(0, Application.HelpFile, HH_DISPLAY_TOC, 0);
Nothing is displayed this way either.
What the heck am I missing here? This is a show stopper if I can't make the help file display when users hit the F1 key.
------ EDIT - PROBLEM SOLVED! ------
Sigh, I'm an idiot, but only partially. :)
The simple app indeed had the help file in the wrong directory. The new Delphi XE2 has the default output in a sub-directory, not the original directory like Delphi 6 used to do. I've been bitten by that twice now. :)
So, once I figured that issue out I had to go back to the original app and figure that one out.
It turns out we had our own HTMLHelpViewer.pas unit in the project (BIG project) and that conflicted with the built-in HTMLHelpViewer unit that comes with Delphi XE2.
Once I whacked our version of that file and removed it from the hard drive and added in Delphi's version everything works swimmingly.
Thanks for the knock on the head to help me figure this out.
The only explanation that I can see, given the information that you have provided, is that the help file is not in the current working directory.
I would keep the working directory out of the equation and set Application.HelpFile to be the fully-qualified path to the help file.
Was the helpfile installed by an installer?
If not, right click it and select "unblock" in the properties
Related
This problem only occurs on applications that were previously designed under Delphi 7 and migrated to Delphi 2007 running on WinXP.
I tried for ages to get this problem sorted with no luck.
As far as I am aware, the Topendialog is a Win32 dialog wrapper and it should inherit the windows folder options which, in my case, is set to show the file extensions of all files.
Now, if I create a new application and drop a Topendialog on it, when it runs, it shows the file extensions as expected.
If I drop the same dialog onto an existing application and run, it doesn't show the file extensions.
If fact if I write a filename string into the filename property before calling the dialog a la 'Myfile.txt', when the dialog is displayed the filename is shown as 'Myfile', the extension doesn't show and neither do any files in the list.
Has anyone else seem this behaviour?
Anybody have any workarounds?
Edit: Images uploaded to shown differences between Topendialog on a new project and existing project.
OK, I have a workaround for this problem.
It turns out that calling SHGetSettings in the right place actually stops the problem from occurring.
So the workaround is to put it in the project source right at the start.
eg
program Blah;
uses
Forms,shlobj,
blah,
.... etc
{$R *.TLB}
{$R *.RES}
var ShellFlags:TShellFlagState;
begin
SHGetSettings(ShellFlags,SSF_SHOWEXTENSIONS); .....
I have no idea why this makes it work, it shouldn't make any difference as its only a query but it works.
So, thanks to Justmade for suggesting that API call.
I just run into a problem that came out of nowhere...
A DFM file gets read just fine from Delphi when project is built, but when I build it from command line (dcc32) I get error Error: RLINK32: Error reading file "update.dfm" Failed read
What is more stranger another project containing same file builds with no error from both Delphi and dcc.
Does anyone have a clue of what could cause something like this?
I tried to build from another location, still same.
Operating system is Windows Server 2008. Permissions seems correct.
Use SysInternals Process Monitor, and watch when it goes looking for update.dfm.
You'll probably see DCC32 frantically searching everywhere for update.dfm (except the place where it is). Or maybe it will find it, but OpenFile fails with an error.
Either way: you'll find out what exactly is going on.
To try and narrow the cause of the problem down, open the dfm with a text editor, and gradually remove properties and save until the build works. That would at least indicate if it's a problem with a particular component in the dfm.
The main thing that is different with a dcc32 is the library path in the environment options. When you build from the IDE this is used. When you run dcc32 you need to specify this.
You can do this by setting the library path for the -I and -U options on dcc32, or you can use a dcc32.cfg file to hold all your configuration for the build.
RLINK32 can signify duplicate resource so consider renaming one of the forms so as to avoid the clash. Having said that hopefully the library path should resolve the issue.
I've seen this happen when you remove a value from an enum type and that value was being used in the dfm. The next time you opened the dfm the IDE would put garbage text in where the value was. Delphi 2010 if that helps.
I would just open the dfm in a text editor and remove the corrupt text.
I found this after having the same problem which seemed to happen randomly from time to time if I changed a bit of code of added a copied a component, this time the only difference I made was changing an = to <> but changing it back worked fine except now I've changed something else it's happening again - hence the reason how I found this. Being quite a newb I didn't really understand some of the other bits mentioned here but I just found by building the project first before pressing F9 seemed to work.. just for now at least.
Hope this helps someone! :)
My system configurations are a follows Delphi2010 on windows 7 professional. I have a problem with some of .dfm files in the project.
I got it as follows. First of all I needed to change some datatypes of TOraQuery component fields from TStringField to TWideStringField and I started it doing manually like opening .dfm change one by one (Find-Replace) everything was fine later on because our project is huge I decided to change everything at once so by using Notepad++ editor and by using option Find in Files and replace all I did replacement. So after this operation I started getting this error like 'TWideStringF class not found' when I wanted to open particular .dfm file. I cannot open this .dfm files even if I press ignore.
PS: Even when I try to open files that has errors in Notepad++ editor to get the line TWideStringF I cannot find it.
How to solve this problem ?
Can anyone give me a clue ?
thank you.
Try finding the "TWideStringF" in ALL your source code first to know where the problem is comming, after that, well, all dependes on what you find!
The Delphi IDE need to be able to find the classes specified in the DFM. It creates instance of these on the design surface for you to interact with.
Editing a DFM by hand is a common practice. I do it often, as sometimes it is faster than any other method. However, it comes with a problem if the class or property can not be found it can cause the DFM not to load. So extra care must be taken to insure that manual edits done correctly.
In this case you can restore the file, and redo the search and replace, or to look at the instances where it's broken and fix them all by hand.
Search for: TWideStringF I suspect you will find that is missing the remaining ield required. Note: Searching in IDE will not work as it won't search DFM files.
After upgrading to Windows 7 all seems to work in my Delphi 2007 version except this one.
I know that 2007 is not build for win 7 but I'm not sure that the OS is the reason. My friend is using it without a problem.
When I use "Find Local References" all is fine.
Do you know a fix for this? Some dll registration may be?
I found the solution!
When I used Refactor -> Rename menu delphi didn't blew up but kindly show me the error. Unavailable interface call with the name of it.
So after short research I've registered 2 tlb files and all is working now.
..CodeGear\RAD Studio\5.0\bin\Borland.Studio.ToolsAPI.tlb
..CodeGear\RAD Studio\5.0\bin\Borland.Studio.Interop.tlb
I used tregsvr.exe for the registration without a problem under my x64 system.
P.S. I still wonder what else is not registered during the installation .. hopefully all is good.
In my application, originally built with Delphi 7, I use the SPHelpIntegration code to enable CHM help via the F1 interface. I figured that this wasn't needed in Delphi 2007, so I removed the units and built my app. I then press F1 and get a message that no help interface is installed. The online help doesn't tell me a lot about what is needed to make F1 help work. Do I have to include a unit or something? Or should I just carry on doing what works?
Add HTMLHelpViewer to your uses clause to handle CHM files. There is an issue in using them is they must exist on the local system (not a network share) to view properly. There is a registry hack to change this behavior, but I have found it easier to just install the help files locally on the system.
Lately rather than CHM files, I used the Adobe OpenPDFParameters API calling conventions to throw them directly into my PDF version of my printed manual jumping to the section based on the current form (I grab the form class name and use it in my named sections). It requires that the workstation has a PDF reader, but who doesn't now days?
Yes, you need to include a help viewer in the uses clause.