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.
| Switch | Where | Value |
|---|---|---|
Registry value ComTrace | HKEY_CURRENT_USER\Software\The White Knight Labs\Access Framework | Full path of the log file |
Environment variable WKL_COM_TRACE | the Access process | Full 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,-Forcereplaces 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.