How does one make their application help file similar to the new windows 7 help format and is that compatible with Windows XP? Can anyone provide details ?
Can we use the windows 7 default viewer as a shell to our own help files????
WinXP only supports Complied HTML (.chm) and the really old .hlp format, if you need anything else on older platforms it might be possible to use the Document Explorer that MSDN uses/used (Not sure if there is a redistributable package without the MSDN stuff you can use)
Related
I maintain a large VB6 application I would like to be able to install on Windows 10. It has a large Help file in WinHelp format. I would like to distribute winhlp32.exe (and winhlp32.exe.mui) with the application rather than replace the winhlp32.exe file in the Windows 10 Windows folder. If I put (an old) winhlp32.exe file in the application folder in Windows 10, and file winhlp32.exe.mui in a subfolder named en-US, the help file works if I enter the command "winhlp32.exe myhelpfile.hlp" in the application folder. However if I run the application exe (created by VB6), and press F1, it runs the Windows 10 winhlp32.exe stub, not the winhlp32.exe in the application folder.
Can anyone suggest how to persuade the VB6 application (before or after compiling it) to use winhlp32.exe from the application folder instead of the Windows folder?
The short story - you may be warned and you know in all it's a heavy task to migrate your VB6 app maybe without reaching a simple way for migrating WinHelp to HTMLHelp.
The official recommendation (10 years old):
Forget about WinHelp, it's history and migrate to CHM help file format.
But, maybe you already have found my answer (search for Run WinHelp on Windows10) and read all further links:
How to convert HLP files into CHM files
Please note a tool called HHPMod especially for migrating context-sensitive F1 help.
I tried the WinHelp of an old VB6 program before and after the fix from above and it is working for me on Windows 10 (Version 1803).
Another solution you may want to try (depends on your deploy and IT environment):
Windows Help Program (WinHlp32.exe) for Windows 8.1 and Windows 7 x64 and x86
Quoted from this article (thanks to Komeil Bahmanpour):
"Please note users who have tried to replace winhlp32.exe manually in Windows folder and winhlp32.exe.mui in Windows\en-US folder of Windows 7, was faced with overwrite restrictions due to ownership and permission problems."
Additional information:
I may well be wrong, but I believe that also (old) online help files are usually copyrighted as part of Microsoft Windows. Distributing the files would normally constitute a violation of copyright law (as you mentioned in your question).
AFAIK developers are not allowed to distribute the Vista version of WinHlp32.exe or included it in their installations. Every individual user who wants to use WinHelp must download the WinHelp update directly from Microsoft and install it themselves.
Help for applications has been .chm for many many years now. Microsoft released the tool HH Workshop (HTMLHelp SDK 1.4) around 1997. Around March 2006 during discussions with MVPs, Microsoft Help team announced that WinHelp would be deprecated (phased out). WinHelp is architected in such a way that Microsoft would have to rewrite it from the ground up to meet the Windows Vista code standards. Since then .CHM has been the only choice for our application help.
What does this mean (please note we are about ten years later now!):
WinHelp runtime (WinHelp32.exe) no longer ships with Windows Vista/7/8/10
ISVs (Independant Software Vendors) should stop promoting WinHelp as a viable help system.
Help authors should move over to HTML Help 1.x (.chm) if they haven't done so already.
HH Workshop is sufficient to author .CHM help files. I'm using a tool with a few more features (drag and drop TOC/Index editing etc) called "FAR HTML". Then there are high-end more expensive tools (you mentioned RoboHelp) that have advanced features such as "convert between different help systems".
Try (untested, but you should get the idea)
Shell App.Path & "\winhlp32.exe myhelpfile"
App.Path gets the executable's current path, so just make sure your winhlp32.exe file is right there with it.
How can I find all the installed versions of Firefox browser on Windows XP ? Is there, for example, a special windows registry key where all the versions are stored ? I need this information in order to code a program that tells me what are these installed versions on my Windows XP. I am not asking you to code the program for me, I just ask where I can find that information.
There are some registry keys accessible under
HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla
I would like ido-find-file to open pdf files with the default programm on Win7. I am aware of ido-default-file-method but there is no customization option that would allow that behaviour.
I solved the problem using the excelent openwith library.
https://bitbucket.org/jpkotta/openwith/overview
I am unable to index contents of LibreOffice files. Files such as .odt files cannot be indexed on Windows Search.
The error says "Registered IFilter is not found"
Any help please?
You installed all the needed optional components i libreoffice installer ?
In the optional features you can select some features that doesn't came in the typical installation.
here is a quick link to a video tutorial an step by step description on how to install LibreOffice
LibreOffice supplies IFilters for 64-bit. Today I updated to 3.6.3.2 on W7_64. The update installed its filters and they did not work. I revert back to the filter from IFilterShop. This one does work (need to read the readme for Vista and W7). Its free for non-commercial usage.
IFilters are used to convert file formats into text for searching. The trouble is that they need to be the same 'bitness' as the app that wants to load them. So if you have a 64-bit app that wants to use the IFilters you need 64-bit IFilters installed.
Have you installed 64-bit Libre Office?
All these years i have been successfully using EnumServicesStatus in combination with OpenScManager (with SC_MANAGER_ENUMERATE_SERVICE) to get a list of the services installed on a computer. This has been working well since NT 4 and up to Vista.
Now, for some reason, in Windows 7 I'm not getting the whole list of the installed services, but only a few of them. No errors, just a very incomplete list of services
Has anything changed in Windows 7? Do I need administrative powers now to enumerate services (I hope that's not the case)? Using Delphi 2010 but the same code was working file in D2007.
I don't think anything has changed here. It would cause huge incompatibilities with old software. But D2007 used the ansi version ENUM_SERVICE_STATUSA and I think D2010 calls the unicode version ENUM_SERVICE_STATUSW. Maybe you are doing some manipulation in the results that assume that the result is ANSI when you are getting Unicode? Just guessing.