Crash Problem -- Help validating an alternate solution

[Mark Strickland]

I am still hunting "gremlins" but when you top 300k lines of code it takes a while!

I put a TRACE in the PB program at the point of a crash and I was able to create a crash with the TRACE ON.  Looking at the trace file does not tell much except where the program stopped (closing a popup form).

As I have dug around in the program I think I have a problem in my Keyboard Hook code in handling F1 for POPUP help.  It seems that the POPUP help is sometimes (but not always) involved in the crash.  That probably explains why some users never see it and others have problems.

I now believe this (described below) is wrong but I put it in some time ago and it worked so I simply "forgot" what I had done.

During a Keyboard Hook call I detect F1 and pop up a modal help window with formname_SHOW.  My guess is this creates "havoc" with memory for other keystrokes that follow and probably creates recursion for each keystroke.

To process context help and to create a VALUE LOOK UP FUNCTION I look at the tag in the field and based on a H=xxx or V=yyy I will pop up a help box or a value select box.  The xxx is a "help code" and the key to a general help Cheetah DB.  The yyy is actually a code to determine which Cheetah file to read to generate the value pick list.  The whole thing is pretty slick except how I pop up the help form.

I don't want to go the EVERY TextBox (hundreds of them) and add help processing in the KILL FOCUS so does this idea (below) make sense?

I could "extract" the POPUP portion and put it in a timer (maybe 50 ms).  I am already capturing in globals, during the Keyboard Hook call, things like the current text box control handle when F1 is pressed (has to be a text box or it is ignored).  The timer could look at the handle and if zero just exit -- or if not then popup a modal relative to the main form.  The timer would also have to have a second flag that says HELP IN PROGRESS so it would simply exit on the next tick if a HELP FORM was POPED UP.  The Keyboard Hook could simply ignore F1 if the current control handle, set by the previous F1, was NOT zero (help in progress).  On close of the HELP or VALUE PICK popup it could zero the text box handle global and clear the timer HELP IN PROGRESS global.  Having the handle of the text box that was active when F1 was pressed is what lets me put the selected value back in the text box on exit using a standard FF_SETTEXT function.

Does a continious ticking 50 ms timer that 99.999% of the time just exits after one IF create much overhead?

To borrow a phrase -- "what a tangled web we weave".

What do you think?

[Roger Garstang]

Why hook F1 when there are other Help related messages that can be checked for?  Couldn't this create problems in other apps, etc?

[Mark Strickland]

I am using F1 since it is the "standard" for HELP.  The Keyboard Hook that I am using is APPLICATION modal so keystrokes from other applications don't process anyway.

It is possible to do a Keyboard Hook that is SYSTEM modal and it will intercept EVERY keystroke.  Just a parameter when you set up the hook.  I did it wrong when I first created this code and it was "interesting".

The real issue is POPING up a form in the middle of a keyboard hook call.

I just about have the code fixed so I will post back the results.

[Roger Garstang]

What's wrong with using WM_HELP?  Same message is sent if you use the Help Context button that appears next to Min/Max/Close too.  I use it all the time and it is much easier than hooking just to get F1.  Only reason I use a hook is for the global form, otherwise standard messages usually work better if just used in the window/app level.

[Mark Strickland]

Makes sense.

Where do you catch that message -- custom event for each form?  The whole point in the Keyboard Hook was to avoid putting the code in many places.  I could probably deal with one per form but what I have now is one for the whole application.

BTW --- the conversion to a timer driven POPUP worked.

[Roger Garstang]

Yeah, the custom event.  lParam is a pointer to a HELPINFO Type.  You can then get the Hwnd and a bunch of other info of the control/form where focus was when F1 pressed.  It is sent to active menu window or window with focus...if no window has menu of focus then sent to current window.  So, may need a function for each form, which could even forward to the parent form, etc if you want a central location for processing.