VB WATCH Frequently Asked Questions

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):
   - threed32.ocx 1.0.0041
   - zip32.dll 2.2
   - zlib.dll 1.1.2
   - gksui16.exe 1.73.236 (uninstaller file) 
   - vbwExtender.ocx 1.0.11 
   VB Watch creates its own directory in your Program Files directory
   Also, the following line is added to your vbaddin.ini file: "VBWatch.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 specified otherwise.
   * 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 made a custom plan with the "variable dump" local error handler
   but without the "variable dump" global error handler in which the vbwErrorHandler()
   function is to be found.
   VBW 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 transformed 
   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)
   - 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.


TIPS

Q1: Can I gather profiling datas on my customer's machine and analyze them on mine ?
A: Yes, you just need to have him run your compiled exe on his machine, and then import 
   his profile files. Here is how:
   - profile your project exactly as you usually do
   - give the exe/ocx/dll that was just compiled to your customer, as well as every 
     files needed to run this exe/ocx/dll
   - once the customer has finished the sessions, ask him to send you the .pfl files
     that were created on his machine (Note: these .pfl files compresses very well, so
     you may want him to zip them)
   - copy the .pfl's in the directory that contains your compiled exe/ocx/dll
   - run the profiler, click the "Clear and load new session" button and browse for the 
     .pfl files.

Q2: Is it possible to run the debugger at a client site to assist in debugging problems
    remotely ?
A: Yes, just make sure that COMDLG32.OCX, MSCOMCTL.OCX, THREED32.OCX, VBWEXTENDER.OCX,
   VBWIPC.OCX and the VB6 runtimes are installed on the client machine.

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.