Color scheme: Light
You are here: start » en » Documentation » Microsoft Access development tools » WKL Forms Object Library » WKL Forms Object Library how-to guides » How to: Collect a trace of the WKL controls for support

How to: Collect a trace of the WKL controls for support

Record what the WKL controls do inside Access - their calls, the messages of their windows and the errors they catch - to a text file, when a problem cannot be seen otherwise.

Requires WKL Forms Object Library, any release.

Solution overview

The trace is off unless one of two switches names a log file. The controls read the switch once, when the first WKL control of an Access process loads; every later line of that process goes to the file. Nothing in the release package, the build tool, the add-in or the bootstrapper sets it, so a delivered application never writes a trace by itself.

SwitchWhereValue
Registry value ComTraceHKEY_CURRENT_USER\Software\The White Knight Labs\Access FrameworkFull path of the log file
Environment variable WKL_COM_TRACEthe Access processFull path of the log file; wins over the registry value

Implementation

# On: every Access started from now on by this Windows user writes the trace.
$key = 'HKCU:\Software\The White Knight Labs\Access Framework'
if (-not (Test-Path $key)) { New-Item $key | Out-Null }
Set-ItemProperty $key -Name ComTrace -Value "$env:TEMP\wkl-trace.log"
 
# ... start Access, reproduce the problem, close Access ...
 
# Off again.
Remove-ItemProperty $key -Name ComTrace

Warning: Do not create the key with New-Item -Force. If the key already exists, -Force replaces it with an empty key and deletes everything below it, including the layouts users arranged in UserForms (Layouts) and the window positions of the designers (Designer).

Send the log file with the steps that led to the problem. Each line starts with the time and the process id of Access.

Remarks

  • Switch it off afterwards. The file is not rotated and grows with every action (a long session can grow it beyond 100 MB), and writing it slows Access down noticeably.
  • Restart Access after switching: an Access that already loaded a WKL control keeps the setting it read.
  • The folder must exist and be writable by the user; a path Access cannot write to is ignored without a message.
  • What it contains. Calls and window messages of the WKL controls with their arguments, and the errors they caught; it can name forms, fields and keys of the application. Treat it like the database it came from.
  • The environment variable is meant for test scripts that start Access themselves; Access started from the shell or by COM does not see a script's environment, which is why the registry value exists.
en/wiki/msaccess/comctl/how-to/collect-a-trace-for-support.txt · Last modified: by Wolfgang van der Stille