Trap PF key events

B

Bill

Sorry, should have put it in quotes, "PF1 event".
The question is: can I trap in the code sheet of
a form when the user presses PF1. If not, then
Access will launch its own HTML Help file.

There seems to be a problem with the API when
user help is launched via the use of context ID's.
I want to code to the API myself to see if I can
identify the problem as being in Access or if the
problem is in the HTML viewer.

Purely for testing purposes, I can obviously use
a command button or other type of control. I'm
just looking ahead to the potential situation wherein
I'll need a work-around.

Bill
 
B

Bill

I just finished testing an invocation of the HTML Help
API with the use of a command button and its click-event
in one of my forms. What fails consistently when using
the forms HelpContextID in Access 2000 works perfectly
if I call the API myself from code.

So, I'm back to my question about being able to trap a
user's use of PF1 to obtain help. I'd really like to mask
the Access problem by running my code versus the
path that would otherwise be taken using the forms
current value of HelpContextID.

I just don't want to put command buttons or other object
controls on all of my forms.

Bill
 
D

Douglas J. Steele

Create an AutoKeys macro that remaps what F1 does to run your own function
instead.
 
B

Bill

Douglas,
Looks like AutoKeys will get the job done nicely. I've
remapped {F1} to run a module that will call the HTML
API. I think my only remaining question is how do I
access the HelpContextID property of the object that
currently has the focus? And, if that object has no ID
assigned, then the HelpContextID of the form or report
that contains that control.

I just need to mimic what Access does.

Thanks,
Bill
 
B

Bill

Douglas,

Excellent!!!

My code intercepts the PF1 interrupt and calls the HTML
API wherein the "autosync" works as designed. I have no
idea what it is that Access does when processing requests
for context sensitive help, but somehow the "autosync"
facility in the HTML help viewer seems to get disabled.

If I get a chance later, I'll install the application on an
Office XP configuration (at another location) to see if it
fails there as well.

Thanks,
Bill
 
J

John Griffiths

See the form object property "Key Preview"
together with the KeyDown/KeyUp/KeyPress events for the form.

I see the annotation PF1 in your question, I associate this
naming scheme with VMS systems, on Windows we have
the 'F' or function keys from F1 to F12 with PrtScrn/Scroll Lock/Break
sometimes called F13 to F15.

Regards John
 
B

Bill

John,

PF1 through PF12 pre-dates the PC's. Somewhere along the road
the "Program" part of "Program Function Keys" got lost in the
transition to PC's. They notation originated on the IBM 2250
high-function main-frame/IBM-1130 attached configurations.
All of that was back in the early to mid-70's. The original function
key table on the 2250 had 32 function keys, whereas the
follow-on main-frame "terminals" only had 12.

Bill
 
J

John Griffiths

Thanks Bill

Coming from the non IBM side I used to believe that screen
based behaviour was inferior to character based behaviour,
as the web is based on passing blocks of data I wonder.

Regards John
 
B

Bill

Hi Albert!
I'm still laughing about this "PFx" caper. And yes, my
historical mainframe comments sort of took me out of the
running for "youngest programmer of the year". We can
go back to the IBM 709 if you'd like.
Bill
 
B

Bill

Douglas,
Liske's article certainly sheds some light on the strange
responses from Access that I've seen in recent days. It
makes it fairly clear why it is that when I call the API for
the HTML Help viewer myself from code that things work
the way they should... SIGH!

Also, as I was thinking about using some "What's This"
popups on controls, I will shift my thinking towards a
different method to accomplish the same thing.

Thanks for the "heads-up" on the URL you posted,
Bill
 
Top