Moving from MZ-Tools 3.0 to 8.0 Part 16: The new Database Connection String Assistant

A handy feature of MZ-Tools 3.0 was the ADO Connection String Assistant, which allowed you to select an OLEDB Provider and to create a connection string for a database, that was copied to the clipboard:

ADOConnectionStringAssistant

In MZ-Tools 8.0, the feature has been renamed to Database Connection String Assistant and it allows you to use either OLEDB providers or ODBC drivers, which are selected in comboboxes:

DatabaseConnectionStringAssistant

If you select the OLEDB Provider option, you get a dialog similar to the one of MZ-Tools 3.0, but without the OLEDB Provider tab:

DataLinkProperties

And if you select the ODBC Driver option, you get a dialog to build the ODBC connection string:

ODBCSetup

Once the connection string is created, it is shown in a textbox and you can either copy it to the clipboard, or insert it directly in the active code document:

DatabaseConnectionString

As it happens with many other features of MZ-Tools 8.0, this is another case where a feature is enhanced to provide more options and flexibility, to increase your productivity.

Moving from MZ-Tools 3.0 to 8.0 Part 15: The Control Explorer and Most Used Properties

Another assistant in MZ-Tools 8.0 that is new for MZ-Tools 3.0 users is the Control Explorer, which shows a tree of controls for the active form or user control, along with a handy toolbar at the top with common actions (view code, bring to front, send to back, copy, paste, delete, apply default properties, etc.) and a grid at the bottom with the (customizable) most used properties for the selected control:

ControlExplorerYou can adjust the height of each zone to occupy the entire assistant with the treeview:

ControlExplorerTreeViewOnlyOr with the grid of properties:

ControlExplorerMostUsedPropertiesOnlyThe Most Used Properties grid only shows the Name property for VBA (due to limitations of its automation model), but for VB6/VB5 is fully customizable: you can click the “Customize…” button to go to the “Options” window, “Personal Options” tab, “Control Explorer” section, where you can select which properties you want to show in the grid for each control. Some properties that are common to all controls (such as Enabled, Left, Top, etc.) can be selected only once using the “VB.VBControlExtender” control, while others that are specific to some controls but not to all (such as Caption, etc.) must be selected individually for each control:

MostUsedPropertiesSo, the Control Explorer is another very customizable feature that will help you to be more productive while designing forms or usercontrols.

Moving from MZ-Tools 3.0 to 8.0 Part 14: Naming controls fast with the Control Name Assistant

MZ-Tools 3.0 provided the TabIndex Assistant to set quickly the TabIndex property of controls. But there are two other properties of a control, the Name and the Caption, that need also to be set and that can be very time consuming. For that purpose, MZ-Tools 8.0 provides the Prompt Name and Caption feature, which was also present in MZ-Tools 3.0, and that asks you the Caption and Name properties. In MZ-Tools 8.0 you can set if you want to generate automatically the Name property from the Caption Property (removing spaces and other characters):

PromptNameAndCaption

And completely new in MZ-Tools 8.0 is the Control Name Assistant, which shows a pair of textboxes for each control where you can enter the corresponding values for the Caption and Name properties:

ControlNameAssistant

The Control Name Assistant allows you to navigate the textboxes up/down and forward/backward with the arrow and tab keys of the keyboard. It also provides a toggle button on the toolbar to decide whether to generate the Name property from the Caption property or not, to further increase your productivity.

With this new feature you can now design your forms focusing first on adding and positioning controls, and focusing later on naming them.

Moving from MZ-Tools 3.0 to 8.0 Part 13: The Code Element Headers Review

A new review of MZ-Tools 8.0 is the Code Element Header Review, that is part of the Quality Review feature. This review is configured in the “Options” window, “Team Options” tab, “Quality Review” > “Code Elements Header Review” section, where you select which code elements (class, enum, event, property, method, etc.) you want to review:

CodeElementHeadersReviewOptions

Once configured, you can invoke the Review Quality feature and select the Code Element Headers Review:

CodeElementHeadersReview

There are two possible causes for a code element to fail the review. In the first one, a code element doesn’t have a header at all:

CodeElementHeadersReviewHeaderMissing

In the second one, the review is smart enough to recognize that, while a code element has a header, it doesn’t match any of the configured headers for that code element. For example, if you have a header template like this:

'--------------------------------------------------------------------
' Method : $P[CODE_ELEMENT_NAME]
' Author : $P[AUTHOR]
' Date : $P[DATE]
' Purpose: $U[Purpose]
'--------------------------------------------------------------------

And the actual header of a method is as follows (notice the missing Purpose line):

'--------------------------------------------------------------------
' Method : f2
' Author : Carlos
' Date : 01/27/2016
'--------------------------------------------------------------------

Then the review will inform that the header doesn’t match any valid header:

CodeElementHeadersReviewHeaderMismatch

So, this new review of MZ-Tools 8.0 is very useful for team leads, consultants or even individual developers that want to ensure that their code is perfectly documented with headers.

Moving from MZ-Tools 3.0 to 8.0 Part 12: Headers for all code elements. With one click.

Another area that has been revamped for MZ-Tools 8.0 is the headers for methods, classes, etc. In MZ-Tools 8.0 the feature is named Code Element Headers, where “code element” means any item such as a class, module, interface, user-defined type (UDT), event, field, constant, enum, property, method, etc. That is, anything that may deserve a header to explain its purpose. In contrast, MZ-Tools 3.0 only allowed a header for files and a header for procedures.

The code element headers are defined in the “Options” window, “Team Options” tab, “Code Element Headers” section, where you can create, modify or delete as many code element headers as you want. You can even make them active/inactive, something useful for consultants working for several clients:

CodeElementHeadersOptions

When you create a code element header, apart from a description and the actual header text (which can include predefined variables and user-defined variables), you select which code elements it applies to:

CodeElementHeaderEditor

When you invoke the Insert Code Element Header feature, if there is only a single header defined for that code element, it is inserted directly. If there is more than one header that applies, you get a prompt dialog to select the desired header, with a preview below the list:

CodeElementHeaderSelection

If the code element header includes user-defined variables, you are asked the values:

CodeElementHeaderUserDefinedVariables

Also new in MZ-Tools 8.0 is the “Insert Code Element Headers” feature (do not confuse with the “Insert Code Element Header” feature, notice the final “s”), that allows you to insert headers to multiple files, to a whole project or to all projects:

CodeElementHeadersInsertion

That feature goes through all files detecting which code elements lack a header and inserts the correct one. It’s a super-fast way to document all the code elements of a project.

But that’s not all, in the next post we will talk about a related feature, the Review Code Element Headers.

Moving from MZ-Tools 3.0 to 8.0 Part 11: Unlimited error handlers

MZ-Tools 3.0 only allowed a single error handler, which was very limited in many scenarios. For example, you may want to use different error handlers for methods in a business layer ActiveX dll and for methods in a user interface executable. Or you may be a consultant for different clients that use different error handlers. In those cases, you needed to change the only error handler provided each time, or use code templates instead.

MZ-Tools 8.0 removes this limitation and provides unlimited error handlers, in the “Options” window, “Team Options” tab, “Error Handlers” > “VBA” section. Furthermore, each error handler can be active or inactive:

ErrorHandlersOptions

The error handler editor is very similar to the code template editor, offering colorized syntax and fields to enter the author, expansion keyword and keyboard shortcut. You can use also predefined and user-defined variables with the “Insert >” button:

ErrorHandlerEditor

When you invoke the Insert Error Handler feature, if there is only one active error handler, it is inserted immediately. However, if there is more than one active error handler, you get a prompt dialog to select the desired one, which you can preview below the list:

ErrorHandlerSelection

To summarize, as it happens in many other areas, MZ-Tools 8.0 removes the limitations of the previous version 3.0, allowing you more flexibility and providing better productivity in your daily coding.

Moving from MZ-Tools 3.0 to 8.0 Part 10: A better Code Library

Another popular feature of MZ-Tools 3.0 was the Add Code Template. In MZ-Tools 8.0 it has been renamed to Code Library and there are actually two code libraries: one in the Personal Options, for your own code templates:

CodeLibraryPersonalOptions

And another one in the Team Options, defined by a team lead with code templates shared for all the developers of the team:

CodeLibraryTeamOptions

The code libraries have root folders for different languages (VB/VBA, SQL, etc.) and you can also create nested folders to group the code templates.

The code template editor has been improved too. Now it has colorized syntax and it allows you to enter the author of the code template and an expansion keyword, which is any text that when typed in a code file followed by the keyboard shortcut associated to the “Expand Keyword” command, it will replace that text by the whole code template. You can also define a keyboard shortcut for the code template, as in MZ-Tools 3.0:

CodeTemplateEditor

Once you invoke the Code Library feature, rather than a modal window, in MZ-Tools 8.0 you get a toolwindow that you can dock, keep floating, move to a secondary monitor, etc. The Code Library toolwindow has two tabs, one for the Personal code library and another for the Team code library. Also new in MZ-Tools 8.0 is a preview of the selected code template:

CodeLibrary

And there is also a button on the toolbar to change the orientation…

CodeLibraryChangeOrientation

… so that you can get the preview below the tree instead of to the right:

CodeLibraryVerticalOrientation

The new Code Library can hold tons of code templates, so it provides a filter to find quickly the desired code template:

CodeLibraryFilter

Finally, when you double-click a code template (or click the Insert button on the toolbar), the selected code template is inserted into the current code file. If the code template contains predefined variables, they are automatically replaced. And if it contains user-defined variables, you get a prompt dialog to enter their values. Also new in MZ-Tools 8.0 is the preview of the code template while you are entering the values:

CodeLibraryUserDefinedVariables

So, the loved code library feature has been completely revamped in MZ-Tools 8.0, to be even much more convenient and to make you even more productive while writing code.

Moving from MZ-Tools 3.0 to 8.0 Part 9: The Programming Rules Review

The Programming Rules Review is also new in MZ-Tools 8.0 and allows you to define custom rules such as:

  • If a ListView has the View property with the lvwReport value, it must have the FullRowSelect property with the True value.
  • The DAO reference is forbidden.
  • The Microsoft ActiveX Data Objects reference is mandatory for ActiveX Dll projects, and its version must be 2.6.
  • A method cannot have more than 10 parameters.
  • The BackColor property of forms must be &H8000000F&.
  • The Height property of the Command controls must be 3600.
  • Code files must contain the Option Explicit statement.
  • The code of a method cannot contain a “forbidden” statement such as GoTo.
  • A method cannot have more than 500 lines of code.
  • Etc.

You get the idea, don’t you? The Programming Rules Review is part of the Quality Review feature:

ProgrammingRulesReview

The programming rules are created, customized and enabled/disabled in the corresponding section of the “Options” window, “Team Options” tab, “Quality Review” > “Programming Rules Review” node:

ProgrammingRulesReviewOptions

You create a programming rule in this window:

ProgrammingRule

As you can see, after an (optional) Id for the programming rule and a description, the first important thing is the item to review, which can be any object or a collection of objects, from the IDE to a parameter of a method:

ProgrammingRuleItemToReview

If you select an item to review that is an object, then you can define a condition that must meet that object. The condition uses a property of that object, and operator, and a value or set of values:

ProgrammingRuleObject

If you select an item to review that is a collection, then you can create two kinds of programming rules. The first kind is a condition about the number of items of the collection:

ProgrammingRuleCollectionCount

The second kind is about the existence of at least one item in the collection that must meet some conditions:

ProgrammingRuleCollectionItemCondition

Each condition that must be met by some item of the collection is created in this editor:

ProgrammingRuleCollectionItemConditionEditor

Apart from the “What to review” tab, there are another two tabs. The second tab sets when to review the item. If you don’t set conditions, the item is always reviewed. But for example, you may want to review something only when its project is Standard Exe, but not when it is an ActiveX dll:

ProgrammingRuleWhenToReview

So, you can define conditions that are combined, and each condition is composed of a property, and operator and a value or set of values:

ProgrammingRuleWhenConditionEditor

The third and last tab is to enter some explanation of the review, and how to fix it:

ProgrammingRuleExplanation

When the Programming Rules Review finds violations of some programming rule, it shows them in the Results toolwindow:

ProgrammingRulesReviewResults

Each result has a context menu where you can locate the result, remove it from the list, or view the rule that has been violated:

ProgrammingRuleView

The following window is shown with the Id, description and suggested fix (if entered when creating the rule). To view the full programming rule definition you can click the “View Rule” button:

ProgrammingRuleViolated

So, the Programming Rules Review allows you to create rules for almost any validation that you want to perform, and it is a powerful tool to ensure that quality rules that are defined by a team lead are enforced. The setup installs some programming rules as samples to get started.

Moving from MZ-Tools 3.0 to 8.0 Part 8: The Nomenclature Rules Review

One feature that was completely missing in MZ-Tools 3.0 was a nomenclature review for the names of classes, methods, variables, constants, parameters, etc. While many teams have some kind of nomenclature standard in a Word or PDF document, it’s difficult to enforce it if you need to do it through manual reviews. MZ-Tools 8.0 introduces the Nomenclature Rules Review as part of its Quality Review feature:

NomenclatureRulesReview

The nomenclature rules are created, customized and enabled/disabled in the corresponding section of the “Options” window, “Team Options” tab, “Quality Review” > “Nomenclature Rules Review” node:

NomenclatureRulesReviewOptions

In that page you have buttons to go to the pages where you define type tags, which can be prefixes or suffixes for types, such as “s” for String, “i” for Integer, etc. and control tags, such as “cmd” for Command, or “chk” for CheckBox. Once you have defined the type and control tags you can start creating a nomenclature rule in this window:

NomenclatureRule

As you can see, after an (optional) Id for the nomenclature rule and a description, the first important thing is the item to review, which can be any object or item with a “Name” property, from the project group file to a parameter:

NomenclatureRuleItemToReview

Once selected the item to review, there are three kinds of nomenclature rules. The first one sets a convention for the name, where the convention is composed of up to two prefixes, a name with a case (upper case, lower case, Pascal case, camel case, etc.), and up to two suffixes. For example, you may want to name member fields of a class with the “m_” prefix (for “member”), followed by another prefix which is the type tag (such as “s” for string, “i” for integer, etc.):

NomenclatureRuleNameConvention

The second kind of nomenclature rule checks that the “Name” property meets some condition. For example, that the name starts with some string, or doesn’t end with some other string, or that matches some regular expression:

NomenclatureRuleNameCondition

The third kind of nomenclature rule is about the length of the name, since you may want to avoid very short or very long names:

NomenclatureRuleNameLengthCondition

You may have noticed that apart from the “What to review” tab, there are another two tabs. The second tab sets when to review the item. If you don’t set conditions, the item is always reviewed. But for example, you may want to review items of an ActiveX dll or control only when they are “Public”, since they are visible to users of your component, and you don’t care so much about “Private” or “Friend” declarations:

NomenclatureRuleWhenToReview

So, you can define conditions that are combined, and each condition is composed of a property, and operator and a value or set of values:

NomenclatureRuleWhenConditionEditor

The third and last tab is to enter some explanation of the review, and how to fix it:

NomenclatureRuleExplanation

When the Nomenclature Rules Review finds violations of some nomenclature rule, it shows them in the Results toolwindow:

NomenclatureRuleReviewResults

Each result has a context menu where you can locate the result, remove it from the list, or view the rule that has been violated:

NomenclatureRuleView

The following window is shown with the Id, description and suggested fix (if entered when creating the rule). To view the full nomenclature rule definition you can click the “View Rule” button:

NomenclatureRuleViolated

To summarize, the Nomenclature Rules Review is very customizable and allows you to create rules for any standard that you may have. It’s ideal for teams, consultants that must follow the naming standards of a client or even for individual developers that want to be consistent in their coding style.

Moving from MZ-Tools 3.0 to 8.0 Part 7: A unified quality review

MZ-Tools 3.0 offered some limited reviews of your source code / form designers: the popular Review Source Code (although Review Dead Code would have been a better name), the Review TabIndex Property, the Review Access Keys and the Review Collections. They could be executed automatically before making an executable or on demand using the Other Utilities dropdown of the toolbar:

ReviewsVersion3

And they were so independent, that each one used its own results toolwindow.

In MZ-Tools 8.0, a unified Review Quality feature is provided through a single button on the Main toolbar:

ReviewQualityVersion8When invoked, you can select the scope of the quality review and the desired reviews, whose number has been doubled:

ReviewQualityUserOptionsWhile the Review Collections has been removed (it can be replicated to some extent as a Programming Rule Review), the following ones have been added:

  • Spell Checker: it can detect typos in the Caption property of the controls or in texts of MsgBox statements.
  • Code Element Headers Review: it can detect not only if a file, procedure, property, etc. code element lacks a header, but also if its header doesn’t match the allowed headers for that code element.
  • Code Elements Order Review: it can detect if the procedures and properties of a file are not sorted as established.
  • Nomenclature Rules Review: although this review will be explained in a future post, suffice to say that it can detect if any name (project, file, control, procedure, property, field, constant, variable, parameter, etc.) doesn’t follow the nomenclature rules that you define (prefix, suffix, case, etc.).
  • Programming Rules Review: this review will be also explained in detail in a future post. It allows you to define “programming rules” or coding standards such as mandatory code, forbidden code, versions of references required, allowed values for properties of controls, colors, etc.

The reviews can be executed also automatically before making the executable, as configured in the Options window, Team Options tab, Quality Review section, where you can configure also each individual review:

ReviewQualityAdminOptions

Once executed, you get a single results toolwindow with all the detected issues (each result shows the individual review):

ReviewQualityResults

So, MZ-Tools 8.0 provides a better tool to detect issues in your projects, source code or form designers, with more reviews and more configurable. This can be invaluable for team leads who can now not only define programming standards for their teams in a tool (rather than, say, in a Word document) but also can ensure that those standards are followed.