>>>>Thank you. But now I am wondering if, when I will be looking at the error log much later after the error occurred, if these values will make sense to me. Ideally it would be nice to know which button or grid or object where the user clicked last (that fired something that caused the error). But I don't know how to get it.
>>>
>>>Either write a hook pattern into the uppermost base class of your clickable controls or employ bindevent() to selectively hook some controls.
>>>Text logs easy and probably not huge (one line per click) but needing to be cleaned on each program start. If you employ a sngle error log, your hook code could also fill a small stack of "latest clicked controls" with timestamp which could be serialized into your errorlog to give "current" latest clicks.
>>
>>Writing a hook pattern or employ bindevent() is over my head. It will most likely break something. And I do maintain a pretty complete text log of errors. But sometimes the description does not give me enough information to duplicate it (on my PC). This is why I will be adding some more info to the text log (e.g. lastkey()).
>
>I think the hook pattern is one of the easiest pattern - but you need discipline in your code if you hook many things, as all methods need to call their dodefault().
>
>Typically it implementation follows the rule of "events call methods" by filling the events in base classes with a simple template like
>
>click_before()
>click_execution()
>click_teardown()
>
>The code often found directly in .click either goes into click_execution or a function called via property.
>Your code for logging would move into click_before()...
>
>For retrofitting code not written along some OOP principles/patterns as main approach, bindevent is a patch often fitting/easier to adapt.
>
>Worth learning - after CA best feature introduced after vfp7 IMO.


I'll just add that I've written about using BindEvent() to keep track of user activity This paper shows how to use BindEvent(): http://tomorrowssolutionsllc.com/ConferenceSessions/Bind%20Events%20for%20Better%20Applications.PDF

What you'd want in this case is to have every KeyPreview on in every form, have the form KeyPress store the keystroke in an application property, and to bind Click, RightClick and DblClick of every control to the form level and then have those form-level events store the action at the application level.
All the work is done in base classes and you can control it with properties, so it only happens when you want it (which in your case, may be always).

Tamar