Cannot find Help file (A2K SR1)

Topic

New Reply

My database A.mdb has a help file A.hlp which I prepared using Help Workshop 4.03. I called the help file using WinHelp() from a routine ShowHelpAPI() which I extracted from NorthWind.mdb, as attached at the end of the post.

The document said that A.mdb and A.hlp must reside in the same folder, which they are. Everything works as expected until I moved A.mdb and A.hlp together to a different folder. When I tried using Help, I got the error message

“Cannot find the A.hlp file. Do you want to try to find this file yourself?”

I tried by hard-coding the full path of my new folder into the code

strHelpFile = “(Actual full path and name of A.hlp)”

It works when I called ShowHelpAPI() from the menu, but when I pressed F1 key, again the same error message appeared.

My questions are:

(a) How do we make A.mdb to look for A.hlp in its own folder, so that it also works when F1 key is pressed?
( I checked the codes in the original ShowHelpAPI(), there is no telling the program that my help file name is A.Hlp, but in stepping into the codes,
strHelpFile = .HelpFile
did show the name of “A.Hlp>Mak” without the full path. How would the program know that?

Thanks.

———————————————————-

Function ShowHelpAPI() As Boolean

Dim hWnd As Long, strHelpFile As String, lngContext As Long
Dim lngRetVal As Long, obj As Object

On Error Resume Next

Const conHelpContext = &H1
Set obj = Screen.ActiveForm

If Err = 2475 Then
‘ Active object is not a form.
‘ Reset Err and test for Report object.
Err = 0
Set obj = Screen.ActiveReport
If Err = 2476 Then
‘ Current object is not a form or a report; show Overview topic.
strHelpFile = “A.hlp>Mak”
lngContext = 100
lngRetVal = WinHelp(hWndAccessApp, strHelpFile, conHelpContext, lngContext)
ShowHelpAPI = True
Exit Function
End If
End If

With obj
hWnd = .hWnd
strHelpFile = .HelpFile
lngContext = .HelpContextId
End With

lngRetVal = WinHelp(hWnd, strHelpFile, conHelpContext, lngContext)
ShowHelpAPI = True

End Function

Reply | Quote

Replies

(1) The NorthWind database has the name of the help file in the HelpFile property of each of the forms and reports. This is how Access knows what help file to open. You could store the path in this property, but it would be very tedious to change this for all forms and reports when you move the help file to another folder.

(2) Windows stores the location of help files in the registry, in HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsHelp. On my PC, there are entries under this key for nwind80.hlp and nwind80.cnt (I use Access 97 = Acces 8.0). The value of both is “C:Program FilesMicrosoft OfficeOfficeSamples” (the folder in which these files are stored). Since these settings are in HKEY_LOCAL_MACHINE, they are computer-dependent, not user-dependent.
You can create or modify the settings for you own database using RegEdit.

Reply | Quote

Thanks HansV. I understand the first part when I looked at the Helpfile property of my forms/reports. I personally put it there myself without realizing that is how Access knows the name of my help file.

The second part still puzzles though. I actually use Application.CurrentProject.Path plus the help file name in
With obj
hWnd = .hWnd
strHelpFile = Application.CurrentProject.Path & “” & “A.HLP”
lngContext = .HelpContextId
End With

When I move the help file and the Access mdb together to another folder, my program can access the help file when ShowHelpAPI() is directly called. The problem is that the help key F1 cannot access the help file anymore (which it did in its original location). I suppose when F1 is pressed, Access looks into the folder of the original help file in the registry. Am I right? Is there any other method where the help shortcut F1 can recognise the new location of my help file as indicated in Application.CurrentProject.Path & “” & “A.HLP”
without resorting to Regedit? I think it is a bad design on the part of Windows if I have to resort to editing the registry just to access the help file when it is moved to another location.

Reply | Quote

I did a few tests. It seems that Access looks for the help file in the Default Database Directory (as set in Tools/Options…, General tab) instead of in the same folder as the database, unless the path to the help file is specified in the Registry. At first I didn’t notice this, because I experimented with a database that resided in the default database directory.
So one workaround would be to place the help file in the default database directory.
I was toying with the idea of intercepting F1 at the form level by setting KeyPreview to True. But I didn’t pursue this, because (1) it would involve writing code for each form, and (2) it wouldn’t work for reports.
Perhaps others have better ideas.

Reply | Quote

Based on the lead given by HansV, I imported the modules basRegistry and basCommon from Chapter 17 of the book “Access 2002 Desktop Developer’s Handbook” by Litwin, Getz, and Gunderloy (Sybex 2001) to change the key data of the key value “A.hlp” of subkey “SoftwareMicrosoftWindowsHelp” of the root key HKEY_LOCAL_MACHINE. (The codes work in A2K as well as A2002.)

When my program starts, it checks if A.hlp is in the mdb directory. If it is, then it will access the registry HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsHelp to look for the key value A.hlp to check if the key data is the same as the directory of the mdb. If it is, then exit sub; else modify the key data to that of the mdb directory. If A.hlp isn’t in the same same diretory of the mdb file, then nothing is done as it is possible that the help file A.hlp could be in the Access default directory and the user installed the mdb somewhere else.

The scheme works. Now the mdb and the associated help file can be moved to anywhere and still the user is able to access the help file by menu or by F1 short-cut. Just to be sure, is there any caveat that I am not aware of to the scheme above?

Still I think the scheme above is an overkill just to make sure the mdb and the hlp files can be moved together anyway in the desktop without the alarming “The file help is not available” message to an unsuspected user. Does anyone has a simpler way of achieving the same thing?

Reply | Quote