Tore already explained my typing lazyness.
If you don't have any coverage / profiling in your classes, either create a singleton object with rudimentary tracing / logging or add fuctionality to app class.
I usually output "app milestones" to file and screen (nowait noclear) with simple info of
datetime, time since last call, possible stopwatch time, function/method name and stacklevel
which is controlled either via some external file setting or existance of flag files.

Normal usage is unhindered, as both are disabled there, but in such cases
user having problem can enable via editing ini / JSON / XML / DBF or creating a file with special name.

If you have speed problems already and want to add fine grained analysis (calls on almost all functions or set coverage often active), you can double guard by creating a special version where these calls are also wrapped by compiler switch, user has to open "tracing app" with active calls.

/upd:
One thing to keep in mind: if error is caused by race condition, timing or similar,
which also happens sometimes when an error only manifests when debugger is inactive,
the error might not come up with wait window output active, as it calls some cleanup.
Often such finer grained analysis is handled by simple numeric switch in logger class:
comparing current setting with setting needed for "analysis that deep"

If you call via

= logger.loglevel >= YOURSPECIALCONSTANT and logger.Log()

your code stays small enough even if you add often on entry and exit of method, as only 2 lines are added.

If your logging needs are heavy and include timing needs,
create routines in C with a simple clean interface

c_log_on(numeric_ident)
c_log_off(numeric_ident)

and handle everything in C variable space to reduce added overhead by a factor of 4 - 10.

If you have code taking exponential times (heavy calc depending on string length with different search patterns), sometimes special routines are needed to identify - you call it with second logger or parameter.

Your case is easy: identify last running method, sprinkle in more loggers or set coverage to special file.

>I can only understand the top of your message. Answers:
>Yes, the error happens only on a client PC, not on my PC.
>I don't know if user input is possible or not. They never tell me the facts.
>What is 'fwk'?
>
>>Not enough info!
>>Guessing:
>>a) error crops up only clientside, not at your machine
>>b) happens before user input is possible
>>
>>basically you should have a logging fwk IAC, which answers this (and timing problems)
>>none exists, and b) is true or error happens with minimal user input,
>>create a version starting with coverage set to a file you can analyze
>>if you have stack in errorhandler, better start coverage at a time "in stack" guaranteed to run,
>>cutting off MB of unneeded coverage log - typical "switch" for me is existance of a flag file.
>>
>>HTH
>>thomas
>>
>>>
>>>I read (again and again) all the messages regarding this problem (in threads I posted before). I also viewed the screen images (my error handler saves the screen image at the time of the error) at the time of the errors. And the images show one of the form (very complicated form) with the PageFrame.Page container showing the page with a Grid.
>>>Note that the error message of this error is caught by the Start() method (the method which calls READ EVENTS and then closes the application.
>>>So, I am convinced that the error is caused by some Thisform.referesh() or another call in this form, when something "odd" happens in the grid.
>>>My question. What type of code do you suggest I add to this form and where to, hopefully, catch this error?
>>>
>>>TIA