What's New in VB Compress Pro?
Revision History of VBCP (Since V4)
| Version | Release Date |
| V6.11 | February 2000 |
| V6.10 | November 1998 |
| V6.02 | May 1998 |
| V6.01 | March 1998 |
| V6.00 | December 1997 |
| V5.10 | October 1997 |
| V5.00 | August 1997 |
| V4.04 | November 1996 |
| V4.03 | June 1996 |
| V4.02 | April 1996 |
| V4.01 | April 1996 |
| V4.00 | February 1996 |
With the November 1998 release of Version 6.10, VB Compress
Pro fully supports all of the new files, formats, features and capabilities of Visual
Basic Version 6. It also remains fully compatible with all previous versions of VB except
VB1. While VB6 support was the primary reason for the upgrade, VBCP6.1 also has many minor
enhancements, some significant new features, and fixes for all bugs reported since the May
release of V6.02.
My initial plan for V6.1 was simply to add VB6 support, fix bugs, and get it out the door as soon as possible so I could get back to work on VB HyperDocs. When I reviewed my file of user suggestions, though, some were just too good to pass up.
VBCP V6.10 fully supports all of the new features in VB6, including webclasses, designer files, call by name, etc etc. If you can write it with VB6, you can analyze and optimize it with VBCP Version 6.1.
VBCP can now save project-specific configuration files automatically, so that the settings you want for one project don't interfere with others. Hats off to Steven Hawkins, who called the old-style save/load options "clumsy" and suggested the new scheme. See Managing Configuration Files for info about this and other new config file options.
Users have been asking for years that they be able to instruct VBCP to ignore certain files in projects, ie to not change them in any way. I've always responded that VBCP is intrinsically project-oriented and can't do this, at least not without a huge amount of redesign and rework. While working on V6.1, however, I thought of a relatively easy way to implement this feature, so I did. Moreover, if you use the project-specific config files just mentioned, VBCP will remember which files you select to be ignored. Hats off to David McCarter and Paul Birkbeck, who asked for it most recently and got me thinking about it. See Selecting Files to Ignore for details.
VBCP now includes the names of related files in project reports, and lets you control how related files are handled in the projects built by VBCP. See Related File Handling for details, and hats off to Craig Johnson who pointed out VBCP's weaknesses regarding related files.
Previously, VBCP expected user controls to be in their own project files, and to be included in other projects as compiled objects. As of V6.1, VBCP now accomodates user controls defined within larger projects, and properly resolves project-wide references to their properties, methods, etc. Hats off to Mark Hallerman and Jan Vrielink for the suggestion.
In previous item cross reference reports, VBCP reported the names of all procedures that referred to the item in question; for example, all procedures that reference the global constant Foo. As of V6.1, item cross reference reports now include the names of ALL items that reference the item in question; for example, any other constants defined in terms of Foo, any static array or type element dimensioned using Foo, etc.
Previous versions of VBCP relied on project file extensions almost exclusively to classify project files by type (form, class, etc), and generally treated all non-standard extensions as modules. I recently discovered that the VB docs are wrong when they say that all post-VB3 file types must be named using the standard extensions; you can indeed use other extensions, and VB will ususally figure out the correct file type. VBCP, however, would not. As of V6.1, the first time VBCP encounters a non-standard file extension in a project, it will ask you to confirm the file type, and whether or not the extension always indicates this file type. Over time, VBCP will thus build a list of all the extensions you use, and what file types they indicate. See Non-standard File Extension Mapping for more info.
Since VBCP can be configured to automatically run VB when it finishes code generation, it needs to know which version of VB a project is associated with. Since Microsoft has been totally inconsistent in changing the version numbers stored in files, this has never been as easy as it sounds, and since Microsoft just did it again, it just got harder. Although the VB6 docs state that VB6 files say Version 6 inside, they don't - they still say Version 5. In fact, unless a VB6 project uses a webclass file, it is virtually impossible to distinguish it from a VB5 project (note that VB itself can't tell the difference). VBCP V6.1 uses some new tricks to make educated guesses, but it also allows you to override the version it selects and select your own. And if you use project-specific config files, VBCP will remember your selection each time you open the project. See VB Version Selection and Override for more info.
Whenever Microsoft adds a new capability to VB - even one
that becomes very popular - it always takes a while before people start using it in all of
the ways that it can possibly be used. VBCP beta testers seldom discover problems related
to new capabilities; not because there aren't any (there almost always are), but because
most testers use the new capabilities sparingly, if at all. The problems surface later,
when developers are using the new capabilities routinely and pushing the envelope a bit.
This is the story with enums, new in VB5. Enums have been
around for over a year, but several enum-related bugs in VBCP (also around for over a
year) have just surfaced in the last 2-3 months. I then reviewed and torture-tested all
enum handling code while working on V6.1, and found more problems. All of the following
problems are now fixed:
> Ian Stirk encountered an SSOOR error in ReadRoutines. Turned out to be a bug in code that executes only when multiple public enums have multiple elements with the same names (this code had probably never executed before!)
> John and Keith at Clandestine Software reported that VBCP identified as unreferenced a file that contained only enums, although the enums were referenced. Bug in the file reference enum resolution code.
> Lapo Cozzutto reported that whenever he had VBCP sort declarations by type, it put enums last. This caused a problem with variables typed as enums. Bug in the sorting code.
> I realized that I had applied the scoping rules for constants and type defs to enums. This was a mistake, because public enums can be defined in file types that cannot contain public constants or type defs. The result was that server mode had no effect on VBCP's handling of public enums, another mistake because public enums ARE written to and exposed by type libraries.
> I also realized that when I fixed the incorrect enum index assignment in V6.02 (see below), I also broke something else that counted on the incorrect assignment. Oops.
David McCarter reported that VBCP was missing two
straightforward references to an API function. I was clueless until he sent me the code,
and then very surprised when I figured out the problem; the missing references were caused
by a fundamental flaw in the VBCP function that evaluates and compares compiler directives
to determine whether conditionally compiled referencing and referenced items will both be
present in a given compilation. In this case, every item was conditionally declared, but
with different and unrelated conditions (the API functions were declared under Win16 and
Win32, the referencing code under a DebugMode directive).
VBCP has always determined "equivalent" compilation directives to match references, but in this case "equivalent" didn't work because DebugMode didn't equate with either Win16 or Win32. VBCP erroneously decided that the reference and the referenced item would never be present in the same compile and hence did not represent a genuine reference. The conceptual flaw was the insistence on equivalence, when what the function really needed to determine was whether the differing compile conditions were mutually exclusive (eg, Win16 vs Win32) or non-mutally exclusive (the case here, IfDebugMode vs Win16 vs Win32). This is now fixed.
Isidro at True North and John Newman both reported that VBCP was having trouble with their projects, and not recognizing references made in the code of their UserConnection designer files. Designer files? Huh? Gee, I thought you wrote designers in C++. Oops, major embarassment mitigated only by the fact that I was far from alone in completely missing VB5's limited introduction to designer files. Since webclass designers are a key feature of VB6, this problem is obviously fixed: V6.1 now knows all about dsr files.
> Tim Miller reported that VBCP missed the reference to the constant that was only used as the default value for an optional argument in a procedure declaration (fixed).
> Dirk Rytlewski requested that when VBCP is configured to comment out unused procedures, please please please have it comment the comments also (now it does).
> Niklas Petersson and a few others reported that VBCP locked up when configured to sort declarations and consolidate globals in huge projects (fixed, although Niklas, your project is so big that now VB instead of VBCP is going to choke on consolidated globals).
> Roger Adams reported that VBCP wasn't removing blank lines when he configured it to single-space the output. I could not reproduce this until I realized that he also had VBCP configured to sort the declarations sections in a certain fashion. Now fixed, this obscure bug dates back to Version 1.0!
> I discovered that when configured to double or triple space the output, VBCP would insert lines in the middle of continued statements, breaking the code (now it doesn't)
> I also discovered that when I fixed command line processing in V6.01 to recognize unquoted file specs, I screwed up certain quoted file specs (fixed).
A few more miscellaneous improvements and changes:
> Some interface improvements ( expanded general options on a nice tabbed page, ability to retain window positions and active tabs during and/or between sessions, etc).
> Improved resolution of identifiers with overloaded names (for those who don't use naming standards, V6.1 is better at telling the difference between, say, a global constant, a form, and a type def all named "PassWord": but shame on you)
> %Project% replaces $Project as the project directory alias used in output specs
I think that's about it. As always, many thanks to the users who took the time and trouble to make suggestions, report
problems, and help me figure them out.
VB Compress Pro Version 6.02 ships in late May 1998 with fixes for the 3 bugs reported since the March release of V6.01. The bugs fixed include the following:
Non-US Date Formats Caused Start-up Errors (16 bit edition only)
It took me forever (well, over 2 months) to figure out what was causing a problem numerous non-US users had with the 16 bit version of Version 6. On startup, VBCP would report "Error Code 0 in GetPut_Cfg", followed by more errors. Even more embarassing, it was a simple problem that I should have figured out quickly.
The problem arose on some (not all) systems that use non-US style date formats as the default. When VBCP read the headers of its OLE (excuse me, ActiveX) cache files, a conflict between a) the embedded date written using US-style MM/DD/YYYY, b) the non-US style system format, and finally c) a bug in VB3's DateValue function, generated the errors. Fixed.
Failure to Recognize Directories with Long Names (16 bit edition only)
Tony McSherry reported that when he selected an existing directory for output, V6.16 a) reported that it didn't exist, and b) tried and failed to create it. Fixed (gee, could this be the last LFN bug in the 16 bit edition?... naaah).
Subscript Out of Range Error Evaluating Types (Both editions)
David Biscoe reported this problem and provided sample code to reproduce it. I discovered that an incorrect index assignment could occur in the EvaluateTypes procedure when a) type elements included Enum datatypes, and b) the project included more types than Enums. I actually fixed this problem and slipstreamed it into V6.01 in early April, but did not document it until now.
Barely Worth Mentioning
It always bothered me that when I loaded a V6 error log into my favorite text editor (TextPad, available at www.textpad.com), the editor reported that the file included binary characters. I traced them to the line reporting OS info, where VBCP was logging the full buffer returned by Win32 instead of truncating it at the first null char. Fixed.
That's it. As always, many thanks to the
users who took the time and trouble to report problems and help me figure them out.
Version 6.01: March 1998
VB Compress Pro Version 6.01 ships in early March 1998 with fixes for all bugs reported since the December 1997 release of V6.0. The bugs fixed include the following:
#Const in Procedures Problem
V6.0 (and all versions since conditional compilation was introduced) counted on the fact that the #Const directive always has module-level scope, and hence belongs in the general declarations sections of files. After Mark Jobsis reported that VBCP V6 was removing a referenced identifier from his project, I realized that if VBCP encountered #Const inside a procedure (which doesn't bother VB itself), it skipped reading the rest of the procedure's code because it assumed it was in a conditional declaration (don't ask why). Fixed.
Another #Conditional Compilation Problem
Alberto Zerolo reported that VBCP was missing references within code that was nested two deep in #directives. Since Alberto was kind enough to provide sample code that instantly reproduced the problem, I traced it to specific circumstances in which a) #directives were nested, and b) there was 1 or more identifiers that were both conditionally and default declared (eg, a constant that had a #Debug definition, a #NoDebug definition, AND an #Else definition). Fixed.
Incorrect OLE Versioning & Infinite Looping on non-US Systems
I was baffled by a handful of reports whereby users would File/Open a project and VBCP would report "Reading Project" and then lock up. Even when users sent code, I couldn't reproduce the problem and I couldn't figure it out. When a 4th report came in, I realized that the only common threads were that all users were overseas, and all were in locales that used the comma, not the period, as a decimal separator. The problem was that a) the version information for one or more of the OLE objects or references in their projects was incorrect, which b) caused VBCP to look for alternate versions, but c) it was using the system decimal separator to construct alternate versions (eg 1,1 instead of 1.1), which d) don't exist in the registry, so e) VBCP merrily incremented the version number towards infinity in a futile quest to find the type library! Oops. Fixed.
Problems Reading Unquoted Command line filespecs
When I introduced handling of quoted command line filespecs to deal with LFN's with spaces in V5, Ken Skier discovered that I also broke the handling of certain UNquoted filespecs. Oops again. Fixed.
Server-Mode Failure to Treat Form-Publics as Externally Accessible
Staale Engen reported from Norway that VBCP6 was improperly removing public properties from forms contained in his OLE Server DLLs. True, because I had neglected to update V6's server mode to reflect VB5's new capabilities to stick user-interfaces on DLL's. Fixed.
$Project Aliasing for Debug File Output
Steven Hawkins reported that when he used the $Project alias to specify the debug output file, V6 crashed ungracefully. This is because V6 didn't support the $Project alias for debug file specifications. As of V6.01, it does (however, it will still crash ungracefully if you use an invalid path).
16 Bit Report Viewer Didn't Support Long File Names
Just when I was getting confident that all of those vexing LFN problems were history, Mark Bax discovered that the report viewer in the 16 bit version of VBCP6 reported "File Not Found" and crashed when handed a long file name. Fixed.
Setting Default Directories Bug
Matt Horne reported that "If you use $PROJECT\DIR for the default directories and then click OK, it always changes the last textbox that the cursor was in to the path that is specified in the drive/listbox combos." Actually it didn't, but a bug in the display made it look like it did. Fixed.
File Size Even Multiple of 20K Problem
Peter Cardiello got "SSOOR in ReadProject" errors. It's a good thing he supplied code to reproduce the problem, because I never would have figured it out. It turned out that because one of his files was exactly 40K in size, and hence an even multiple of 20K, VBCP's line counting procedure errored out and returned a 0 line count. Fixed.
Line Continuation in Empty Argument List of External Function Declaration
Peter also received an Illegal Function Call in EvaluateDeclares. The problem here (which could be safely ignored) was the use of a line continuation character between the parentheses of a function declaration with no arguments (ie, Function Foo Lib "xxx" ( _<newline>)). The space preceding the line continuation character was causing VBCP to attempt to evaluate the empty list. Fixed.
That's it. As always, many thanks to the users who took the time and trouble to report problems and help me figure them out.
Parallel 16 & 32 Bit Editions
The single biggest difference between VBCP V6 and V5 is that V6 includes almost identical 16 and 32 bit versions. V6.16 thus makes available to 16 bit users virtually all of the new features introduced since Version 4. In addition, and contrary to what you might think, V6.16 is NOT limited to 16 bit VB and Windows. With robust 32 bit subsystems that kick in when run under Win32, V6.16 works flawlessly with all versions of VB, including VB5. In fact, you'll be hard pressed to tell the difference between 6.16 and 6.32.
This is obviously a bonus for the still substantial number of 16 bitters out there, but is there any reason why 32 bitters should care? Well, yes, actually, I think there is. First, as discussed in the 16/32 Bit Differences topic, V6.16 significantly outperforms V6.32 under some circumstances! More importantly, though, is the technology behind V6 which allows me to compile both editions from a single VB5 code base. To do so, I created a tool that reads VB5 projects and uses compiler directives and other tricks to generate VB3-compatible versions. This tool, as discussed in more depth under VB5To3, is currently an in-house effort only, but could easily be brought to market if interest warranted. Drop me a note (bcw@whippleware.com) if you're interested.
Recreate Directory Trees
All previous versions of VBCP wrote new code files into a single output directory, regardless of the original project's directory structure. V6 now offers you the option of recreating projects' directory structures. See Recreate Project Directory Tree for more info, and hats off to Mans Ohrstrom for the suggestion.
Display & Report File Path Information
V6 offers you the option to display and report full and/or partial pathing information for all project files. See Show Paths for details.
Robust VB Control
As discussed below, VBCP's capability to control VB has grown more complex and less reliable over time. After making numerous reliability improvements in V5.1, I stepped back and revisited the issue from scratch. The result, in V6, is completely new control code that is far simpler and more reliable than the old stuff. I have also fully integrated the command line control option, so that, for instance, VBCP will now report EXE size even when compilation is commanded via the command line.
That's about it for VBCP Version 6. I don't need to end this with my traditional "thanks for helping me find the bugs" because none have been reported since the release of V5.1. The only problems have been people getting the 32 bit version when they needed 16, and vice-versa. Version 6 fixes that. But as always, many thanks to the users who have helped make VBCP the best VB analysis and optimization tool you can buy!
VB Compress Pro Version 5.10 ships in late October, 1997. Thanks to the skill and hard work of the people who beta tested Version 5.0, very few bugs have been reported in the three months since 5.0's release Those that were reported mostly affect obscure options that few people use, like string matching. So without many bugs to fix, what's a developer to do? I decided to add and improve features.
New Features & Improvements
Interface Improvements
The most visible change in V5.1 is the Code Options window, where the expanding clutter of previous versions has been replaced with a clean tabbed page that presents VBCP's many code options in five groups. Various options have been moved around for coherence, and ALL code options are now available on the code options window (to the distress of batch mode users of versions 4.x through 5.0, a few options were only accessible in interactive mode, after analysis was complete).
Expanded Assertion Capabilities
VBCP has always had a rudimentary "assertion" capability that could insert a single statement containing procedure names into each procedure. VBCP now recognizes and expands 10 variables, has a built-in assertion code editor, and can even expand and insert entire files stored on disk.
Plug Plug Plug: This enhancement is a small preview of a new product I'm working on. Look for a full blown VB preprocessor from WhippleWare sometime next year.
Command Line Control of VB
VBCP now allows you to call and control VB from the command line, as well as via VBCP's traditional "Interaction with VB" techniques. There is room for legitimate debate whether this is really a new feature or a bug fix, because difficulties controlling VB5 was by far the most common problem reported with VBCP 5.0 (see below). In any case, command line control of VB after generating code is a new and reliable way of doing things. And for your convenience, the VB Command Line Arguments help topic summarizes what you can do from the command line.
Batch Process List Files from the Command Line
If you start VBCP with the /L switch followed by the path and name of a valid list file, VBCP will batch process all VB projects listed in it, in accordance with current option settings.
Expanded/Exposed Debug Mode
VBCP's debug mode has been expanded from 2 to 3 levels and presented on the general options windows (in place of VB paths, which have been relocated to the VB Interaction page of the code options window). Debug mode has also been better documented.
Under the Hood: Tune Up & Some New Parts
I've made two types of changes under the hood:
1) A parsing engine tune up. Although the changes are unlikely to reduce significantly the time it takes to analyze entire projects, VBCP now analyzes certain types of VB code with more intelligence and less brute force. This applies primarily to OLE-specific code, ie the kinds of coding you couldn't do in VB3.
2) New parts. When I wrote VBCP5 as a VB5 32 bit app, I decided that the 16 bit version had reached the end of the road and made no accommodations to easily incorporate new features and bug fixes in both versions. This was a mistake because a) the 16 bit business continues strong, b) I've been adding new features to V5 that I would like to incorporate in the 16 bit version, and c) I've decided to stop selling separate 16 and 32 bit versions and instead to package and sell them together as a single product (this will happen soon). To do this, I've retrofit V5.1 with new calls and components to make it easy to maintain a common code base across VB3 and VB5.
Bug Fixes
As mentioned above, not many bugs were reported in V5 and most that were affected obscure options that few people use, like string matching and declarations sorting. On the other hand, a bug's a bug: here's what's been fixed:
Erratic Control of VB
By far the most commonly reported problems with V5 related to controlling VB5. While many users had no problems, others reported that after generating code, V5 would start VB5 and then either stall at the "new project wizard" or create the default "Project1" and return. Other users reported that V5 acted differently when VB5 was set up to use its SDI and MDI modes, respectively. Still others reported that their VB5 add-ins were getting in the way.
VBCP controls VB in a way that MSFT never intended it to be controlled. This has gotten more difficult over time, as VB's start-up sequence and IDE have grown more complex and unpredictable, and as you've become able to run more than one instance of VB simultaneously; FYI, VBCP5.0 needed ~100 lines of code to control VB3, ~400 to control VB4, and ~800 lines for VB5. And with the arrival of add-ins that allow users to customize VB's start-up, reliable control of VB5 has become almost impossible, at least via the unconventional methods used by VBCP. Hmmm, what to do?
Well, I started by giving up and adding the option of controlling VB via the command line, as discussed in the Interaction with VB topic. This works very well in all circumstances. However, it also sacrifices the VB error trapping and other bells and whistles that VBCP offers when controlling VB using its traditional methods. Thus after implementing command line control, I invested a fair amount of time trying to reproduce users' problems and fix them. Certain add-ins are always going to cause problems, but I think (hope) that you'll find V5.1 does a much better job controlling VB5 than V5.0 did. If not, please let me know, and fall back to the command line option.
String Matching (Oops!)
VBCP's string matching function obviously isn't too popular, because V5's didn't work very well but the bug went unreported for months. In fact, turning on string matching caused V5 to encounter a Stop statement and bomb instantly. I'm pleased to report that string matching now works fine, even if nobody cares (the guy who reported the problem didn't even know what string matching was; he'd turned it on by accident).
Long File & Path Name Problems
Silly me, I figured I'd left LFN problems in the dust when I moved to 32 bits. Not so. V5 had three bugs relating to long file and directory names. First, it would blithely pass long filespecs on the command line to VB3 and VB4 16, which they obviously didn't like. Second, it would pass unquoted long filespecs containing spaces to all versions of VB. Finally, it wouldn't accept quoted long filespecs containing spaces on its command line. These are all fixed.
Alias Directories Failure in Batch Mode
When run in batch mode, V5 failed to create aliased directories and would stall with a "path not found" error. Fixed.
Sorting of Enums, Implements, Withevents, Etc
VBCP's declaration section reordering capability must be another one of those unpopular things, or maybe all of my cautions in help about using it on VB4+ code have scared people away from it. In any case, V5 had a bug that caused it to sort new VB5 things like Implements statements, WithEvents variables, and Enums right into the twilight zone; they would disappear when sorted. If anyone besides Ramon Guerrero cares, all VB5 items are now sorted properly.
Overloaded Property Procedure Names
If a project had a global variable and a property procedure with the same name, V5 treated all references to the the property procedure as references to the variable, and would identify the property procedure as unreferenced. Fixed.
Incomplete Removal of Continued Comments
Yet another lightly used V5 option - the Remove Original Comments function - had a problem with continued comments, ie comments that used the line continuation character to extend beyond one line. Specifically, V5 would remove only the first line and leave the rest. Fixed.
Typelib Cache Duplication
As noted in What's New in V5, VBCP can now cache multiple versions of type libraries. However, a bug in V5 caused it to continually re-cache newer versions, leading to multiple entries in the cache. This is fixed.
Note: If you have installed V5.1 over V5, it would be a good idea to delete all files in the ODF subdirectory, EXCEPT VBVBA.ODF. This insures a clean cache, as VBCP will rebuild it as required.
Error Evaluating Routines with Optional String Argument
V5 (and V4, for that matter) would report an IFC error when evaluating routines if the routine's declaration supplied a default value for an optional argument, the value was a string, and it contained a comma. The error could be safely ignored. Fixed.
That wraps up the changes in V5.10. Thank you for buying it and as always, many thanks to those of you who found problems and took the time and trouble to help me figure out and fix them.
Ben Whipple
With the 8/97 release of Version 5, VB Compress Pro now fully supports all of the new files, formats, features and capabilities of Visual Basic Version 5. It also remains fully compatible with VB2, VB3, and both flavors of VB4. While support for VB5 was the primary reason for the upgrade, VBCP5 also sports numerous minor enhancements, some significant new capabilities, and fixes for the handful of bugs reported in V4.04.
The biggest underlying change is that VBCP5 is a pure 32-bit app, written in VB5 and VC++5. Because of this transition, VBCP5 has intrinsic support for 32-bit-only features as OLE drag-and-drop, the Win95 common controls, etc. It means that the extensive thunking VBCP4 did to support LFNs and other 32-bit features are history, along with the occasional (mostly NT-related) problems that thunking entailed. Of course it also means that VBCP5 requires 32-bit Windows, and also the VB5 runtime files, which we refuse to install because of the interdependent support file fiasco that recent MSFT products have created. You must have a working install of VB5 on your machine to install and operate VBCP5.
VB5 Support
VBCP5 fully supports all of the new project types, files, formats, features and capabilities of VB5:
> VBCP5 works with all VB5 project types, including ActiveX controls, documents and servers, as well as standard executables.
> VBCP5 understands and properly interprets all new language features, such as Implements, WithEvents, and RaiseEvent.
> VBCP5 extends its capability to identify, xref, and remove dead code items to VB5's new code items, including Events and Enums.
In short, if you can write it with VB5, you can analyze and optimize it with VBCP5!
Other New Stuff
VBCP is a focused tool, and with each rewrite I always resist the urge to turn it into a Swiss army knife by loading it up with new features. On the other hand, I also try to incorporate worthy user ideas and suggestions, especially those that make it easier to use and/or more useful to a large number of customers. That said, here's what's new and improved, beyond VB5 support, in VBCP5:
Drag & Drop
If you drag and drop a VBP or MAK file on VBCP5, it will open the project for analysis. Drag and drop a TXT file and VBCP5 opens it with the report viewer. Thanks to John Cohron for suggesting this (and the VB5 team at MSFT, too, for making it so easy to implement).
Relative Output Directories with $Project
Many users have requested the ability to have VBCP automatically direct output to subdirectories of whatever project it's working on. VBCP5 can do this, via the $Project alias for the current project directory. See Setting Default Directories for details.
Property Procedure Handling
VBCP now allows you to specify different handling and reporting options for property procedures than for "regular" sub and function procedures. Thus, for example, you can configure it to ignore unreferenced properties but remove uncalled subs and functions. These new options are included with the Item Handling and Item Reporting options.
Analysis Mode
I'm particularly pleased with VBCP5's Auto-Select Analysis mode, which replaces VBCP4's Server Mode option. When set, VBCP automatically adjust its reference-searching mechanism when working on different kinds of VB5 projects. See Analysis Mode for details.
Query Before Removing Unused...
Since V4, VBCP has had the ability to identify unused OLE objects and VB code files in VB projects. When it came time to write the new project, it always queried the user about each file. V5 has a new option that can suppress this tedious querying: see Project File Code Options for details.
Improved Viewer
With the transition to 32 bits, VBCP5 is able to use a rich text box control for the integrated report viewer and still handle huge report files. The benefits include standard editing capabilities (ie, cut and paste), simpler scrolling, and neater repainting. The downside is the loss of backwards-searching, which is not implemented in the Win32 API and was SO SLOW done in code that I removed it.
Project Information List Improvements
Right-click the project information list on VBCP5's main window and you'll get a menu that lets you control list content and format, and/or dump the list to the clipboard, the printer, or a file.
Reporting Enhancements
VBCP5 incorporates many small improvements in its reporting capabilities:
> The project summary section now gives a quick count of used versus unused OLE objects and references.
> The file details section now reports whether each file is in use. When reporting on a VB4 or later project, it no longer contains the obsolete format field (ie, binary vs Ascii).
> The code-by-category section now reports the number of trailing comments as well as the number of full line comments (VBCP5 also fixes a bug that caused VBCP4 to under-count comments: hats off to Tim Patrick for finding it)
> The file header section now documents VB's hidden file attributes (eg PredeclaredID, GlobalMultiIUse, etc)
> All dates are now shown using locale-specific formats (thanks to deserved nagging from Tim Jones)
TypeLib Versioning
VBCP4 could only work with a single version of a type library, and required the user to manually delete older versions from its cache before it would recognize and read newer ones. VBCP5 can cache multiple versions of the same typelib (ie, typelibs with the same GUID) and properly recognizes typelib version info in vbp files. It also maintains date information and automatically rebuilds its cache when a VB project references a typelib that has the same GUID and version but a later date than one already cached (If you really care about the nitty gritty of this stuff, see Managing OLE Description Files).
Recent File List Size
A new general option allows you to set the size of the list of recent files that is appended to the main file menu (big deal, huh?).
Documented Debug Mode
VBCP's debug mode is now documented: see Debug Mode for info.
Minimize While Running
Thanks to persistent suggestions from Mans Ohrstrom and preemptive multitasking under Win32, VBCP's status window now has a minimize button. This means that you can drop VBCP into the background while it works.
In Closing...
That about wraps up the changes in V5.0. Thank you for buying it, and many thanks to those of you who took the time and trouble to help with the beta.
Ben Whipple
Version 4.04 of VB Compress Pro shipped on 11/8/96. V4.04 fixes all bugs and problems reported since the 6/96 release of V4.03. The bugs fixed are as follows:
Public/Private Options Reversed
In all previous versions of VBCP4, the public/private unreferenced item handling and item reporting options were reversed (ie, VBCP handled/reported privately scoped items the way you configured it to handle/report publicly scoped item, and vice versa). This was an extra embarrassing screw-up, and I'm amazed that it went undetected/unreported for so long! Hats off to Jean Paul Sirois.
Note to Upgraders: Because of this reversal, it's possible that configuration info stored in the [UnrefAction] and [ReportItems] sections of your current INI file has illegal values. If you've tinkered with these settings, you should delete these sections before running V4.04. If you don't, you may get some weird error messages.
Missing References
V403 sometimes missed indirect references to object properties and methods when the references used VB's ActiveForm and Parent object syntax.
V403 missed references to MODULE-based property procedures (not form or class properties) if the reference did not include the module's classname.
V403 had a hard-to-explain bug that could cause it to mis-id the object type when you used the "Set x = y" statement; the mis-id could cause VBCP to miss references to props/methods of the object type in question.
LFN Problems
When the report file VBCP was asked to generate had a long name, V403 would create an empty file every other time it generated the report (actually, this isn't quite true: VBCP would create the file, but some peculiar behavior of Win95's hybrid 16/32 file system tricked VBCP into deleting it). Scrolling the scroll bar in the empty report viewer that then appeared would cause an untrapped SSOOR and crash VBCP.
When reports included File Details, VBCP would encounter two File Not Found errors in PrjFileDetails if the EXE file name in the project file was an LFN.
V403 would not recognize long directory names used for reports and code targets in list files used for batch processing.
Note: If you use LFNS that have spaces in them in list files, you MUST enclose them in double quotes (Asc 34).
New feature: As suggested by Aaron Judah, if your list file specifies report/code directories that don't exist V404 will create them for you.
Colon Problems
A change made in V403 to deal with multiple, colon separated, statements on a line introduced two problems:
Colons in Trailing Comments: V403 would leave in the stub of the line to right of the colon when omitting rest of line
Colons in Date/Time format (eg #8:00:00#) caused an SSOOR error in ReadRoutines
Line Continuation Problem
V403 sometimes output uncompilable code when it id'd and removed unused items that were declared in compound lines (ie, lines that used the line continuation character). Specifically, if the first or last line contained items to be removed, VBCP's editing left a line stub with improper syntax.
Note: When VBCP is going to remove/comment/modify any item declared in a compound line, as of V404 it now turns it into a single line, without any l/c characters. This is the only reliable way to avoid the 10! ways that such a line can be mucked up.
Item XRef Report Bug
V403 pointed at the wrong initial element when reporting Item XRef Classes, and hence reported Form references instead of Class references.
Errant Line Delete of Redim of Array in Global/Module UDT Variable
V403 was confused when a member array of a global or module-scoped UDT variable was redimmed locally, and could delete the line.
That's about it. As always, my apologies to users who had problems and many thanks to those of you who took the time and trouble to make suggestions, report bugs, and help me figure them out.
Ben Whipple
Version 4.03 of VB Compress Pro shipped on 6/14/96. V4.03 fixes all bugs and problems reported since the April release of V4.02. The changes include the following:
Indirect Referencing Fixes
The biggest changes in 4.03 have to do with proper resolution of object property and method calls when the object variable is initially dimmed as a generic object and instantiated later as a specific object of type X. As VBCP is essentially a static analysis and optimization tool, it still has problems resolving object types that are unknown until runtime. However, V4.03 now does exhaustive checking and recursion to track unresolved public property and method calls back to base forms and classes.
V4.03 may still not be perfect in this regard; however, I have adopted a conservative strategy that should never miss a reference. The downside is that if other objects have identically named public props/methods that are in fact not called, VBCP may leave them in.
Special thanks and hats off to Mark Bax and his team, whose GenericAssay application makes such sophisticated use of VB4's new object-oriented capabilities that it baffled both VBCP and myself. V4.03 can handle GenericAssay, giving me confidence that it can handle just about anything.
Improved Property Procedure Resolution
V4.02 had various problems with property procedures. Sometimes it missed references, other times it mis-id'd them, eg treated Gets as Lets (prime example: a Get inside If...Then was treated as a Let).
If a property reference was inside a With...End With, V4.02 properly resolved it but then failed to mark the proc as referenced.
V4.02 treated the return value assignment in a property get as a reference to the property let.
V4.03 has no (known) problems with property procedures.
Server Mode Fix
The effect of turning on Server Mode -- designed for optimization of OLE servers -- has changed.
In previous versions, when Server Mode was active VBCP would treat all public members of all forms and classes as referenced, and would never remove them (it basically handled them like event procedures). It would, however, report them as unreferenced if it did not find internal references.
This was flat-out wrong due to my ignorance (what, read the docs?), and many thanks to the users who patiently set me straight. Public stuff in forms is only accessible internally, and public stuff in classes is only accessible externally if the class itself is marked Public. Thus as of V4.03, Server Mode causes the automatic inclusion only of public stuff in public classes.
Reporting is also changed: when Server Mode is active, V4.03 reports as referenced all public methods and property procedures in public classes.
Duh!
Long File and Directory Name Fixes
Implementing full support for long file and directory names in a 16 bit app has proved to be more complicated than I anticipated, but I think that V4.03 irons out the final kinks.
If a VB4_32 VBP file had long directory names embedded in the file specs, V4.02 would choke with an SSOOR error in its GetVBProject routine and was unable to read the file.
Although never reported, I realized that under very rare circumstances V4.02 could fail to recognize a long filespec as a long filespec. As this was a "theoretical" bug, I'm not sure what symptoms a user would have seen.
For reasons that still puzzle me, the LFN thunk occasionally fails under Windows NT. VBCP has always been prepared for this; should the thunk fail, it pops up the LFN resolution window and allows the user to resolve overlapping long and short file names. However, if there are more than 4 forms with LFNs with identical first 8 chars, under NT VBCP does not always return all candidates for assignment. V4.03's "fix" is the More button on the LFN window, which lets you pick any file you want for assignment (I'm not particularly proud of this, but it works).
V4.03 now accepts project file specs containing long file or directory names on its command line.
Change in Ignore/Mark Unref Procedure Handling
VBCP's default behavior is to NOT examine unreferenced procedures for other references (if the proc isn't called, none of the references in it are valid). However, when configured to Ignore or Mark unreferenced procedures, VBCP includes them in the code it produces, and thus should examine them; otherwise, items that are referenced only in these procs will be omitted and the code won't compile. VBC3.X was smart enough to do this, but until V4.03, V4.x was not.
Recovery from Invalid Font Problems
2 users reported errors with V4.02 while trying to generate reports; a variety of IFC errors and such in VBCP's ComposeReport, ProjectReport, and other procedures. With their help, I traced the problem to invalid font settings that were in turn causing VBCP to format reports with 0 characters per line. Should V4.03 encounter an invalid font setting (caused, for instance, by selecting FontX in one printer, then switching drivers to a printer that didn't support FontX), it will instantly pop a font dialog and request the user to select a valid font.
VB Interaction Fix
When VBCP's VB Interaction option is set to anything besides None, VBCP starts and controls VB when it finishes generating code. After starting VB, however, V4.02 sometimes failed to recognize that VB was running and simply returned to the Generate Window (if DebugMode was active, it would report a VB CONTROL FAILURE). Fixed.
No More Missing Backslash in Suggested Filenames
If default directories no longer existed, V4.02 would omit a slash when constructing suggested names for output using the temp directory. V4.03 does not.
OK to Omit Final CRLF
If the last line in a code file didn't have a final crlf, V4.02 would generate an SSOOR error when rewriting code. V4.03 does not.
OK to Name Forms with Extension other than FRM.
If a form file had an extension other than FRM, V4.02 treated it as a code module. This caused event procedures to be omitted, and a bunch of other problems. V4.03 does not make this assumption.
OK to Nest Compile Conditions
If the code inside a procedure nested conditional compilation directives more than 2 levels deep, V4.02 would generate an IFC error in ReadRoutines. V4.03's conditional compilation stack grows as deep as it needs to grow to handle any nesting depth.
Multiple Declaration / Multiple Line Fix
During VBCP4's first pass through a project, it builds a table of pointers to the locations of procedures within files (this is one of the strategies that makes it so much faster than V3.x). V4.02 screwed up these pointers when a) conditional compilation was used to give a single procedure multiple declarations, and b) the declarations themselves were spread across multiple lines using VB4's line continuation character. The result was SSOOR errors in VBCP's ReadProject, ReadRoutines, and RewriteCode procedures. V4.03 figures the pointers properly.
SetupWizard and "Path="
2 users reported that the VB4 setup wizard ignored their instruction not to regenerate the EXE when run against VBCP's code, tried and failed to have VB4 recompile it, and then failed altogether. This happens, it turns out (who knows why?), if you insert a "Path=Dir" statement into a VBP file, where Dir is the same as the directory where the project is located. Thus V4.03 does not insert a "Path=" statement in the VBP file it creates if the path you specify for the executable is the same as the project directory.
OK to Mix Const or Dim with Executable Code
V4.02 would improperly omit executable code during rewrite if the code was on the same line as the declaration of an unreferenced local constant or variable. If configured to remove unref local constants, for example, V4.02 would omit "x = y + 1" from the following if ConstantX was unreferenced.
Const ConstantX = "Foo": x = y + 1
Note that V4.02 did NOT have this problem when the trailing statement was another Const or Dim statement, only when it contained executable code. During design, I considered this and decided that nobody would ever put executable code on the same line as a declaration or dimension statement. Live and learn; V4.03 allows it.
No Problem with Procedure Description Attribute
V4.02 could get confused by the description attribute that VB4 sticks in the top of procedures when you use the object browser to insert a description (you don't see this attribute in VB4's editor, only if you use a text editor to view the file). In any case, if you included the name of the proc and certain other text in the description, V4.02 behaved unpredictably. V4.03 does not.
No More Type Mismatch in OnePerLine
VB's Val() function has a bug and generates a type mismatch error when passed certain combinations of single letters and type declaration characters (eg, D%, D&). In V4.02, the error was trapped in the OnePerLine procedure and reported to the user. In V4.03, it is trapped and handled internally.
Improved Debug Mode
VBCP's undocumented debugmode has been made slightly more accessible and generates more info (to activate/deactivate debugmode, set the focus to the Debug Statements dropdown list on the Code Options window and hit F10).
OK to Cancel Code Categorization
V4.02 generated an untrapped overflow error and died if you started code categorization, then canceled it. V4.03 does not.
I think that's about it. As always, my apologies to users who had problems with V4.02, and many thanks to those of you who took the time and trouble to make suggestions, report bugs, and help me figure them out.
Ben Whipple
Version 4.02 fixes the following problems that originated in V4.0 but were reported after release of V4.01:
When the Override "All File Settings" boxes on both the Unref Item Handling and Item Reporting windows were checked, VBCP4 would generate an error in GetPut_Cfg when it saved its configuration file.
VBCP4 would miss indirect references to public methods/properties when the instance of their class was an element of a user-defined type. If Form1 had a public Foo method, for example, VBCP4 would miss the following reference:
Type tagFoo
Frm as Form
End Type
Dim MyFoo As tagFoo
Set MyFoo.Frm = Form1
MyFoo.Frm.Foo
If your code added an item to a collection, did not use named args, did not specify an index or sequence args, and if the name of the item had the word "Item" in it (eg "objItem"), VBCP4 would generate an Illegal function call error in ReadRoutines (which could be safely ignored).
VBCP4 had a version check error that caused it to mistake Win 3.1 for WinNT. This didn't cause any problem in V4.0, but it caused a BIG problem (ie, an immediate GPF) in V4.01 when run under Win3.1 (not 3.11, however). I actually fixed this problem in V4.01 after shipping only a handful of copies.
If a form referenced itself by name in an event procedure, but was in fact never loaded or used, VBCP4 did not properly flag it as unreferenced and offer to remove it. For example, if Form3 was in your project and was never loaded, but had a line in Command1_Click() reading Unload Form3, VBCP left the form in the project.
The Set All controls on all option windows are now all initialized as blank.
As always, my apologies to anyone inconvenienced by these bugs, and my thanks to the users who took the time and trouble to help me figure them out.
Ben Whipple
VB Compress Pro 4.01 shipped on April 1, 1996 (no fooling, 4.01 on 4/01).
V4.01 contains much improved support for long file and directory names, fixes for all bugs reported to date in V4.0, and even has a new feature or two.
If you haven't already, be sure to read What's New in Version 4.0.
Long Filename Support
V4.0 supported long file names to the extent that it could read VB project files that had them. In retrospect, this was pretty lame, and I apologize to the 32 bitters out there who put up with having their LFN's converted into short names.
V4.01 does a lot more thunking to the Win32 API and provides almost seamless support for LFN's. It uses, displays, and preserves LFN's everywhere it encounters them. It also allows you to create directories with long names. The only time VBCP's 16 bit roots show through is in the file dialogs, which are 16 bit controls and will inevitably display "C:\Progra~1" instead of "C:\Program Files," for example.
Speaking of LFN's, V4.0's setup program had a bug that caused it to fail to properly register the exe if it was installed in or under a directory with a long name.
Indirect Referencing
V4.01 has some significant internal changes to deal with indirect references to public methods and properties of VB4 forms and classes.
To understand these changes, consider the following example:
1) All forms in a project have a public Foo method.
2) There are no direct references to any of these methods (eg Form1.Foo, Form2.Foo) anywhere in code.
3) However, all ARE in fact referenced:
a) There is an ExecuteFoo procedure that takes a form as an argument.
Sub ExecuteFoo (frm as Form)
frm.Foo
End Sub
b) Somewhere in code, there's a loop that calls ExecuteFoo and indirectly references all of the foo methods
for i = 1 to Forms.Count
ExecuteFoo Forms(i-1)
Next
V4.0 would miss these indirect references and strip the Foo methods out unless server mode was on. V4.01 will not, as long as the Indirect References advanced code option is checked (which it is by default). See Advanced Code Options: Indirect Referencing for more info.
Other Bugs Fixed
1) By far the most frequent cause of V4.0 tech support calls was a misleading dialog box that popped up the first time VBCP needed to run VB, if it hadn't found the path in VB.INI during installation. The dialog is titled Specify VB Executable File, and the pattern given was *.EXE. At least 10 people (I stopped counting) interpreted this to mean the EXE for their project (eg PROJECT1.EXE), and called to report that VBCP had run their project and stopped dead. The pattern is now set to VB.EXE or VB32.EXE, as appropriate. Whoops! Never underrate the importance of human factors!
2) If a VB class had methods/properties with the same names as standard VB form properties (eg Width, Left), V4.0 would generate a subscript out of range error in ReadRoutines (which could be safely ignored).
3) If a local variable dim'd as a user defined type was given the same same as the UDT (eg Dim Envt as Envt), V4.0 treated the ref to the UDT as a ref to the var. If this was the only ref to the UDT, V4.0 missed the ref and omitted the UDT.
4) If a procedure was defined more than once with different compilation conditions, AND if the ref to any of them was indirect, AND certain module or global level identifiers were ONLY ref'd in the indirectly referenced one(s), V4.0 would miss the ref's and omit the identifiers.
5) V4.0 generated an untrapped overflow error and blew up when a project had a large number of declarations and certain other circumstances prevailed.
6) If a VB3 project declared the same API function twice with the same scope, V4.0 would not mark EITHER of them as referenced, and would strip both.
7) Since V4.0 didn't use long names, when it copied a FRX file it had to go into the FRM file and change the long name.frx to shortname.frx. It sometimes missed a few, causing problems with the imagelist Win95 control.
8) V4.0 nuked the entire line of code when it began with an unref label and VBCP was configured to remove dead labels (which it is by default).
9) If a user changed the code output directory in the textbox on the generate code page, V4.0 reset the default to the new directory even though it wasn't supposed to.
10) If a user aborted from an error caused by LFN's during the generate code stage, V4.0 kept running but was invisible.
11) In V4.0's Set Def Dirs window, answering NO to xxx doesn't exist, attempt to create it? could sometimes (not always, a gotfocus timing quirk) result in an untrapped Path not found error and a crash.
12) A rare combination of project code and V4.0 report option settings could generate a Subscript out of range error in DetailSection.
13) If a procedure had more than one declaration (ie different compilation conditions) for the same body of code, AND V4.0 identified unref'd local stuff near the top, a bug in its internal line counting logic could cause it to comment out/remove the wrong lines.
14) The /INI command line option didn't work (this was actually reported and fixed in the first week of V4.0's release).
15) When configured to strip blank lines, V4.0 didn't strip lines with embedded tab characters.
New Features & Enhancements
1) Al Franz suggested that batch processing would be more useful if VBCP allowed you to direct output (reports and code) into different directories. This was a terrific idea (thanks Al). If an entry in your list file specifies a valid directory after the project path & file name, V4.01 will direct both reports and code to it. If you specify two directories, V4.01 directs the report to the first one, code to the second one.
2) Also at Al's suggestion, if you run a batch with NOSTOP checked, V4.01 will not stop for overwrite confirmation, even if overwrite confirmation is checked.
3) At the suggestion of the testers at the Crescent Division of Progress Software, V4.01 now updates the project information header on the main window as soon as it attempts to load a project. This guarantees that the header and the contents of the list box stay in sync, even if a load fails.
In Closing...
That about wraps up the fixes and changes in V4.01. My apologies to users who had problems with V4.0, and many thanks to those of you who took the time and trouble to make suggestions, report bugs, and help me figure them out.
Ben Whipple
In a word? Everything!
Although Visual Basic 4.0 resembles VB3, users discover quickly that it is a fundamentally new product. Much as we would have liked to do some tinkering and get a compatible version of VB Compress Pro out the door, we had no choice but to perform an equally fundamental redesign. All 35,000+ lines of code in VBCP4 are new..
Starting over with the knowledge gained supporting thousands of users for more than two years was a real opportunity to improve the product. Venerable old VBCP3 accumulated many patches during its run, and we accumulated a long list of customer ideas that couldn't be implemented in VBCP3. So our design goals expanded beyond VB4 compatibility; we aimed for maximum benefit from experience, to eliminate all patches, and to incorporate as many customer suggestions as possible. VBCP4 arrives on the market later than we had hoped (so what else is new), but we think - and hope you agree - that it was worth the wait.
VBCP4 has many new features and capabilities, but there are two that VBCP3 users will notice first and appreciate most: performance and mode of operation.
Performance
At the heart of VBCP4 is a significantly smarter, faster parsing engine that analyzes VB code in 30-40% of the time it took VBCP3. We're proud of the technology in this engine. VBCP4 uses all of its speed but not all of its brains, so - plug plug - look for an interesting new product later this year.
Mode of Operation
In VBCP3, you selected a project, set directories, configured options, started the operation, and waited for completion. If you wanted to change a single option setting, you repeated the entire process. In VBCP4, the time-consuming analysis step has not only been sped up (per above); it has been separated out and made independent of option settings. In VBCP4, you File/Open a VB project and Analyze it without worrying about option settings. When analysis is complete, you then fiddle with options and generate multiple reports and optimize code in a few seconds per run. Thus a single run in VBCP4 is 50% faster than VBCP3, but two runs are 85% faster.
If the beta testers were representative, you may need a few minutes to get used to the new mode of operation, but will strongly prefer it when you do. Still, there may be times when you wish to operate old-style, by setting options up front, clicking a button and going away. If so, just File/Open the project, set options via the options menu, and select Analyze [ProjectName] on the batch menu. See Batch Processing for more info on how VBCP4 can optimize single or multiple projects with minimal intervention on your part.
So What Else?
Although the basic structure of VB Compress Pro 4 is radically new, the basic functionality is unchanged: VBCP4 analyzes VB projects, identifies everything that is declared, defined, and dimensioned at every level of scope, and determines what's used and what isn't. It generates a variety of reports telling you what it found, and generates new copies of code omitting, marking, or commenting out the dead stuff. That said, VBCP4 offers you new features and enhancements at every step in the process. You'll have to dive in and use it to discover all of them, but here's some of the most significant.
General: Multiple Configuration Files
VBCP4 lets you maintain and use multiple option configuration files: see Working with Alternate Configuration Files
Reporting: New Sections, New Information, New Precision
VBCP4's reporting capabilities now include 4 new sections: project level file summary, control information, and procedure and item cross-reference reports.
The project level file summary is a concise description of project files, including such tidbits as a list of DLL's for which the project declares procedures and whether or not any of them are called; a list of OLE controls and whether they are used; a list of compile conditions; and a count of files that use (and don't use) Option Explicit. See Project Level File Summary for more info.
There are two highly-customizable cross-reference reports available. Either or both can be created for the project as a whole, for the files in the project, and for the procedures in the project. The Procedure XRef reports, with sections for each procedure, tell you which identifiers (constants, variables, etc) are referenced in each procedure. The Item XRef reports, with sections for each selected item, tell you which procedures reference the item. VBCP3's lack of xref capability has been a frequent user gripe, so we've been studying competitive products and are confident that these reports put us ahead of the pack.
VBCP4's report engine also has a new feature called Name Construction, which propagates through all sections of all reports. Name construction allows you to control the level of detail reported about each identifier by making it part of the reported name. If you set Data Type to Always Report, for example, VBCP includes the data type whenever it reports a variable or function name. This makes tasks such as finding unintended variants as simple as generating and searching a project-level report. Other elements available for name construction include class name, compile condition, scope, procedure type, control class, and library. See Report Options: Name Construction for more info.
Finally, VBCP4 gives you much more precise control over report content by allowing you to specify content by file type. When you call up the Item Reporting or XRef Reporting window, you are presented with a tabbed page on which you can set different rules for form, class, and module files. Having made such elaborate choices, moreover, you can override them simply by toggling the Override All File Settings option on and off.
Code Optimization: New Features and Refinements
VBCP4's new optimization features range from major improvements to minor refinements. The most significant are the Project File options that let you identify and eliminate entire files - including forms, classes, modules, and OCX controls and other OLE objects - that are declared but never used (for more info on how VBCP "does" OLE stuff, see VBCP, VB4+, and OLE).
The new Reordering options let you sort and reorganize declarations by type, by compile condition, or both (before using them, though, please see why sorting and consolidating is so complicated in VB4+).
Server mode lets you optimize VB4 server apps that are, by design, loaded with public stuff that is never called internally.
The menu of choices for handling unreferenced items has expanded; if you select the new Interactive setting, VBCP will query you for decisions as it rewrites your code. Also, you can now configure VBCP to handle items differently depending on the type of file they are located in. See unreferenced item handling for more info.
Some of the many minor enhancements are:
> The help system comes with a spiffy new add-on that lets you browse, print, and perform full text searches.
> Assertion code can include carriage returns (just use the | pipe character)
> Debug statements can be matched on how they end, as well as begin.
> VBCP4 can thoroughly document the changes it makes to your code via comments at the top of each file; but you can also turn off commenting.
There's lots more, but it's time to dive in and see for yourself. Thank you for your business!
Ben Whipple
In the years that I've been selling VB Compress Pro, hundreds of users have helped me improve it by making suggestions, reporting bugs, and helping me figure them out. Thank you!
I wish I had started this topic years ago, because at this point it's impossible to reconstruct the list of everybody who's helped. In the spirit of better late than never, though, I'd like to get started by acknowledging the people who've contributed since I began work on Version 4. And please accept my apologies if I've missed anyone.
In no particular order...
David McCarter Joe Paquette Bruce Kellerman
Michiel de Bruijn Steve Bell Salvatore Caronna
Ken Kaplan Aaron Anderson Steve Carrothers
Tim Hitchings Steve Malmgren Bill Loytty
Rick Marlette Al Franz Markus Kreisel
Scott Fisher Lawrence Calmus R. Rasanen
Earl Phillips Bernie Elmsley Andrew Kornberg
Jean-Louis Darnault Darrell Roberts Mark Bax
Art Purcilly Joe Lahoud Erik Ruud
Herb Eber Jan Kuhlman John Grant
Bob Stratton Duncan Bradley James Thorpe
Ros Krayterman Alex Lee Thomas Steiner
Jose Gracia Jr. Dave Wilson Russell McCullen
Chris Rogers Gary Heaton Patrick McHargue
Jean Paul Sirois Mark Alsop Walt Edwards
Fred Thorlin Doug Strauss Frank Gerber
Laurence Hill Julie Greenwood DJ Kengott
Ron Nelson Ron Braithewaite David Haber
Ed Lorden Ron Young Aaron Judah
Ivan Brock Steve Greensill Tim Jones
John Cohron Dean Cleaver Dick Butler
Jeffrey Ogata Rod McCulley Tim Patrick
Mans Ohrstrom Ramon Guerrero Mark Fuggiasco
Monte Hansen Adam Klette Brad O'Keefe
Alloys Petrarca Robert van den Breemen
Craig Prichard John Thomson JP Roberts
Mark Jobsis Steven Hawkins Staale Engen
Lapo Cozzutto Alberto Zerolo Alex Peake
Peter Kovacs Peter Cardiello Matt Horne
Ken Skier Dirk Rytlewski Victor Wallenberg
Charles Lindquist David Biscoe Tony McSherry
Jules Moorhouse Bas Smulders Lars-Gunnar Segerfeldt
Richard Brooker Piazzini Sandro Eduardo Gibba
Kjell Boye Dave Crookes Tom Kinzelman
Paul Birkbeck Tim Miller Mark Hallerman
Charles Havranek Jan Vrielink Ian Stirk
John and Keith at Clandestine Craig Johnson
Niklas Petersson Isidro at True North John Newman
Roger Adams