CHM files and their locations

I am not sure this is a FTN95 problem, Windows 10 problem, or 'other'. I found this interesting.

I am experimenting with HelpScribble to create the CHM (HTML Help) files. Using Plato, I created a short program to experiment with 'HELP_CONTENTS' and 'HELP_LOOKUP' callbacks. None would work. The callback would open the Microsoft website and the text there was regarding WinHelp formatted help files. So, confusion.

Yet, by changing the file name, IO could access FTN95.CHM with no problem (full path as the file name). I used the example in the existing help file.

I had HelpScribble place my CHM file on the desktop, pointed the test program it and voila! All worked.

I verified that the full path name I had used for my test case was also correct, and it was. Tried again, failed. Confused even more.

One this that is different is that the folder in which the test CHM file was originally placed is in my DropBox , and further, the folder is a sub-folder of a mapped drive. I know CHM files cannot be accessed off of a network/mapped drive without registry changes. In my test case, however, I specified the full path using the physical drive (D:) to start my path. So I figured (incorrectly?) that I would be safe.

Now that I know what I am dealing with, I can accommodate this 'quirk', but wanted to ask if others had any issues like this when similarly configured, and if so, was there a fix? Or, perhaps there is something in the Windows API that gets really nit-picky about where the CHM file is?

Bill,

I'm not sure if this helps, but I put my CHM file in the folder where the EXE and SALFLIBC.DLL reside, all done with Jordan Russell Software's InnoSetup. The default program name (in this instance) is SS.EXE, and the Helpfile is WSXHelp.chm

I find the installation folder at runtime by using GET_PROGRAM_NAME@, and chopping SS.EXE off the end of the command line argument string, and replace it with WSXHelp.chm to call with HH.EXE

At some point I decided that even if the program wasn't named SS.EXE, I could find the path by counting back from the end of the string returned by GET_PROGRAM_NAME@. I forget why, perhaps in case someone manually renamed it. But if they rename the help file, or move it, then they can take the consequences. The following should be reasonably clear:

      INTEGER FUNCTION IHELPSYS()
C     --------------------------
       CHARACTER*(256) PNAME
       INCLUDE <WINDOWS.INS>
C      -----------------------------------------------------------------
      IHELPSYS = 1
      CALL GET_PROGRAM_NAME@ (PNAME)
      CALL UPCASE@ (PNAME)
      N = LEN_TRIM (PNAME)
      IF (PNAME (N-5:N) .EQ. 'SS.EXE') THEN 
      N = N - 6            ! Assumes SS.EXE
      CALL START_PPROCESS@('HH.EXE',PNAME(1:N)//'WSXHelp.chm')
      ELSE
      DO 10 I=1,N
      J = N + 1 - I
      IF (PNAME(J:J) .EQ. '') GO TO 20
  10  CONTINUE
      RETURN
  20  CALL START_PPROCESS@('HH.EXE',PNAME(1:J)//'WSXHelp.chm')
      ENDIF
      END

It's a callback function for both the menu item Help|User manual and the toolbar Help button. No doubt there are other, and possibly better, ways.

Eddie

Eddie, thanks for the reply. I already do something similar to find the executable path. I just happen to use INDEX to find the last backslash (the .TRUE. optional 3rd parameter to index). This way, it is executable name independent.

Yes, I know that saving the CHM file in the executables folder would be the right thing to do for the user, and for building an install script.

The issue is that the behavior is odd, even given Microsoft's refusal to have an HTML help file opened on a network drive.

I have further investigated, and it is because the help file location was on a mapped drive that this occurs. So, mapping a physical folder to a drive letter, then using something in that mapped path to reference the help file causes the issue.

Bill