GENERAL INFORMATION
Q1: What changes does the VB Watch installation make to my system ?
A: The VB Watch setup file installs the following files in your Windows\System directory (unless a newer version is found):
- BDir.dll 1.0.0
- ccrppgr6.ocx 1.4.0.22
- ccrpudn6.ocx 1.3.0.9
- CSWSK32.OCX 2.20.0.2160
- gksui16.exe 1.73.236 (uninstaller file)
- MSINET.OCX 6.0.81.69
- TabDockVBW.ocx 2.3.0.4
- unzip32.dll 1.1.0.0
- vbwFunctionsVB6.dll 2.0.0.0
- zlib.dll 1.1.2.0
VB Watch creates its own directory in your Program Files directory
VB Watch uses the following registry keys: HKEY_CURRENT_USER\Software\VB and VBA Program Settings\VB Watch*
Also, the following line is added to your vbaddin.ini file: "VBWatch2.Connect=3"
Q2: How does VB Watch Protector affect my code, in terms of speed or size ?
A: First you should keep in mind that VB Watch does not alter your original source code unless you select that option deliberately.
* Adding error handlers to every procedure may double or triple the size of the compiled exe, but doesn't slow down the code.
* Adding procedure calls tracing increases the code size and decreases the execution speed a little bit.
* Adding line tracing increases the code size and decreases the execution speed a lot. This should be reserved to debugging purposes only.
Advice 1: to reduce the size of your exe, you may use an exe compacter. For example, the size of the "VB Watch Profiler.exe" file was reduced by 65 % using such a tool.
Advice 2: you can use tags to exclude some particular procedures or modules from being processed.
TROUBLESHOOTING
Q1: Sometimes, when VB Watch compiles a transformed project, VB crashes and then VB Watch asks if I wish to load the transformed project in a new VB session. What happened ?
A: VB Watch compiles using the VB command line with the /m switch (m for make) like this:
"<path to vb6.exe>" /m "<path to project>" , letting VB do the job.
It appears that this command can make VB crash with some projects. It happens also when you enter the command via the Windows Run box (Start / Run...), so it is not a problem from VB Watch.
Fortunately, only the VB session freshly started by the command line crashes, so the VB session with VB Watch is still alive. VB Watch detects this and proposes to load the transformed project in a new VB session, from which you can successfully compile using the File/Make... menu.
Q2: I get a Compiler Error: "Variable not defined" on the line "Case vbwDoDumpVariable"
A: You have used the "Local error handler with variable dumping routine" without the corresponding Global error handler "Send mail (Variable Dump)" in which the vbwDoDumpVariable is defined.
Q3: I get a Compiler Error: "Sub or Function not defined" pointing at the following line:
Select Case vbwErrorHandler(Err.Number, Err.Description, VBWPROJECT,VBWMODULE, VBWPROCEDURE, Erl)
A: You have probably created a custom plan, reusing a local error handler containing the vbwErrorHandler procedure but without implementing vbwErrorHandler in your global error handler.
VB Watch 2 lets you select the local and global error handlers separetely but you must make sure that they are compatible.
In this case the local handler calls the vbwErrorHandler function that you must implement by the mean of the global handler, or by any other mean.
Q4: I profiled a project, ran several sessions, and then stopped using the instrumented project code in order to make some changes to my original source. Now whenever I run the original source code, I see the profiler window at the end, and VB Watch has created a new session.
A: There was one or more activex project in your project group. At the time of profiling, they were compiled - thus Windows registered the new compiled version (with profiling instrumentation).
Now each time you use a project referencing those activeX, the profiled version is used, and when the activex is destroyed, it generates a pfl file.
2 possible solutions:
- register back the old copies of your ocx/dll (using regsvr32.exe)
- recompile them from the original source code
Q5: I have my own error handler in some procedures, but I would like that VB Watch handle all errors that are not already handled by my own routine. Yet VB Watch writes an Exit Sub statement just before writing its handler, so it is never executed.
A: Use the tag vbwNoExitProc that was created for this situation - see help in the Tag Reference section.
Q6: I do not get any profile results showing in the Profiler when I use the Internal method. Yet the .pfd file seems to be created but it stays almost empty. Note: this shouldn't happen with v2.0 anymore.
A: The code for writing the .pfd
results file is in the Class_Terminate event of the CvbwProfile.cls
class that is added to your project. It is automatically executed in
most cases, when this class goes out of scope at the end of a session.
But it won't, for example if you run a project from the IDE and click
the End button in the VB toolbar to terminate your session, or
if a dll stays in memory. You must manage to execute the following
line right before clicking the End button:
Set vbwProfiler.c = Nothing.
TIPS
Q1: Can I gather profiling data on my customer's machine and analyze them on mine ?
A: See How to profile the execution of your project on another machine.
Q2: Is it possible to run the debugger at a client site to assist in debugging problems remotely ?
A: See How to debug an application running at a remote site.
Q3: Is it possible to profile an activex dll, ocx or exe?
A: See How to profile an activeX dll/ocx/exe.
Q4: Is it possible to profile an IIS dll?
A: See How to profile an IIS project.
KNOWN BUGS AND LIMITATIONS
Q1: I get a "Procedure too large" compile error
A: Taken from Visual Basic documentation:
"Each procedure can contain up to 64K of code. If a procedure or module exceeds this limit, Visual Basic generates a compile-time error. If you encounter this error, you can avoid it by breaking extremely large procedures into several smaller procedures, or by moving module -level declarations into another module."
VB Watch needs to intrument your code by adding lines of code in your own procedures.
Therefore, if one of your original procedure is close to 64 Kb, the instrumentation may cause to exceed this limit and the compilation fails. This is especially true when using the "line tracing" feature or the "profile line" option, because VB Watch needs to write one additional line for each line of your code like this:
vbwTraceLine 36
ff = FreeFile
vbwTraceLine 37
Open lFile For Input As #ff
To work around this limitation you can:
- split the large procedure into two or more smaller procedures, which is generally a good practice in VB programming. You may use a tool like "Project Analyzer" to help you identify the procedures to split - see our site www.aivosto.com/ for more infos.
- use the vbwNoProfileLine or vbwNoTraceLine tags. Put this in a comment in the first line of the large procedure like this:
Sub MySub()
' vbwNoProfileLine
Note: using a tag in the module declaration would affect all the procedures in the module.
Limitations:
- In the following line:
Label: A = 8 : Resume next
Label is always interpreted as a procedure and VB Watch splits this line to:
Label
A = 8
Resume next
The VB Watch parser does not have the capability to decide whether it is a label or a procedure.
To make sure it is interpreted as a label, do not write any statement after the label, like this:
Label:
A = 8: Resume next
Single line procedures such as:
Sub Hello: MsgBox "Hello": End Sub
are not correctly interpreted. Please do not use semicolons around procedure headers.
Variables, user-defined-types and objects declared in a TLB file might not be recognized properly when using the variable dump feature (Protector tool). If you get a compile error on a line written to report the contents of such variables, you will need to comment out this line to continue.