Known bugs and limitations in Project Analyzer 4.0
==================================================

Please report any new bugs to vbshop@aivosto.com. If you can, please
attach a short code file or project to facilitate debugging.

Some of these limitations are on a to-do list, some can't be fixed at
all. 


PLEASE NOTE THAT THIS LIST INCLUDES MOSTLY MINOR BUGS THAT OCCUR IN SOME
SPECIAL CASES ONLY.

===========
Limitations
===========

- Project Analyzer (32-bit) has no known limit to the size of projects 
  it can handle.
- The size of variable, constant and procedure names is restricted to 64
  characters to save some memory. Longer names are truncated.
- There are limits to the number of references registered.
  From a procedure to other procedures    max 100 calls / procedure
  From a module to other modules          max 100 calls / module
  To a module from other modules          max 200 calls / module
  Variable, constant, Type and Enum references are not limited
- Super Project Analyzer can handle max 50 projects at once

==================
Known misbehaviour
==================

- Long lines don't word wrap on some report types
- Long procedural call tree reports (All procedures) can hang the computer
- In the hypertext window, letters in DefType statements may be 
  mistaken for one-letter variable names
- In the hypertext window, if you have two different definitions with the
  same name (e.g. Form1.MyVar and Form2.MyVar), the program may
  highlight the both in red when only the other one should be highlighted
- If a local var/const has the same name as the procedure it's in, the
  procedure name will be mistaken for the var/const name in the
  Hypertext window and Project Printer. This has no effect on the
  analysis, though.
- If a procedure and a module have the same name, this can result in 
  erroneous references to the procedure instead of the module.
- If an array defined as New ObjType is later ReDim'd, the ReDim doesn't
  count as an assignment but a reference, even if the ReDim creates new
  objects in the array.
- Variants are classified as non-object variables, even if they contain
  an object, because there is no way to detect this at design-time.
  This may lead to minor flaws, like with the below code:

   Dim v as Variant
   Set v = Form1
   v.Caption = "This is my form"
     
  Here the last statement is considered an assignment to v, although,
  strictly speaking, it's a reference to v (and assignment to Caption). 
  Fortunately, this doesn't do much harm. If v was defined as Form, 
  there would be no problem. 
- In the following code
  For x = 1 to 10 : Debug.Print "Hello world" : Next
  X is reported as Used only in assignment, even if it really is
  referenced by the For...Next statement.

===============================
Deficiencies in VB 3.0 features
===============================

- The Summary report shows somewhat distorted figures for 
  1. Global Name Table: Type definitions and DLLs declarations are
     not calculated correctly.
  2. Global Symbol Table: type definitions are excluded, and everything 
     else is assumed to take 10 bytes of memory.
  Use freeware VB Space (by Gregg Irwin) for more exact calculations
- Can't analyze files saved as binary. Save as text instead.

===============================
Unsupported VB 4.0/5.0 features
===============================

- Compiler directives (#if xyz then)
- Line continuation character "_"

- Late-bound references. Example:
  Forms(2).DoSomething 

  Project Analyzer can't know which form the call goes to, because 
  Forms(2) may be of any of your forms. This applies to all object
  references that are of a general type (e.g. As Form, As Object) 
  and not a specific type (As MyForm, As MyObject).

===========================
Unsupported VB 5.0 features
===========================

- Controls on UserForms (.dsr/.dsx files)
- Inherits statement (polymorphism) supported partially. A procedure that 
  implements an interface procedure is dead only if the procedure it 
  implements is also dead. That's because polymorphed calls are bound 
  finally at run-time.
- If a class is supposed to be used outside the project, its members 
  may be "dead". This is a problem e.g. with ActiveX EXE/DLL projects.

========================
Deficiencies in FRX view
========================

- Supports the most usual data types and controls, like PictureBox.Picture,
  ListBox.List, ListBox.ItemData, TextBox.Text, MouseIcon etc.
- Some properties that are not supported (others exist):
  AniButton.Picture, SSCommand.Picture

======================
Help Compiler Warnings
======================
You can ignore the following warning in HCW.EXE:
HC2002: Note: 
    The keywords "xyz" and "Xyz" are identical except for case. 
    Help Workshop has modified one keyword to match the other.


================
For best results
================

- Always declare your local variables (use Option Explicit)
- Always save your files as text (VB 3.0)
- Use MS Word as RTF editor
- Wait for the analysis to end completely (it has 2 phases)
- VB 5.0: Project Analyzer is at its best analyzing Standard EXE 
  projects. You can of course analyze ActiveX projects too, but
  public classes, for example, may have "dead" members that aren't
  dead in reality (because they are used outside the project)

