MDUF

Preparing Legacy UserForms for Capture

In my experience as an MDUF user[1], I’ve found that if a UserForm is working in Excel, MDUF can capture it, with the exception of dynamic Pictures and MouseIcons. But the effort required can vary dramatically from one UserForm to the next. Preparation makes all the difference.

Consistency can be lost over time

When preparing a project for capture into MDUF, a good general guideline for producing a maintainable result is to first restore consistency. Use firstParagraphconsistent naming conventions, a consistent color scheme, consistent sizes, consistent fonts, and consistent control placements.

Enormous simplifications in the capture process are possible if the UserForms of the project are consistent. Consistency in design, function, naming, and code can reduce the effort required to capture them into MDUF. Most systems are consistent when first created, but over time, as they’re extended and improved, consistency can suffer.

For example, consider the command button usually captioned as “OK”. Over time, this button might acquire various names on various UserForms. It might be named OK, OKButton, cmdOK, cmdOKButton, and even CommandButton1, just to name a few. And when the name of the control varies, so does the name of the Sub that handles its Click event. If consistency suffers, maintainability suffers as well.

An example of the value of consistency

As an illustration of the value of consistency (and the cost of inconsistency) consider the command button usually captioned as “OK”. In most cases, clicking this control is intended to initiate two processes. One process invokes a Sub that takes actions determined, in part, by the state of the controls of the UserForm. Another process hides or possibly unloads the UserForm.

If the control’s name is cmdOK, the name of the Sub that invokes these processes is cmdOK_Click . On the FormSpec worksheet for this UserForm, you can enter the code for cmdOK_Click directly. MDUF’s UserForm generator inserts that code into the UserForm when you invoke the UserForm generator. For a UserForm called QueryUser, in its simplest form, the code might be:

Private Sub cmdOK_Click()
	Hide
	HandleQueryUserOK
End Sub

Actually, this form of cmdOK_Click follows the general form for many UserForms’ OK handlers:

Private Sub cmdOK_Click()
	Hide
	<handler-name>
End Sub

Control naming conventions consistent from UserForm to UserForm thus imply back-end code consistent from UserForm to UserForm.

Consistency in control names and their prefixes

Naming controls consistently is important, as discussed in the previous section. Another opportunity for increased consistency is the prefix used in a control’s name. The prefixes used in MDUF are discussed in the section, “Naming controls“. These prefixes are recommended. It is also recommended that before capturing a UserForm, the UserForm and all its controls have names that use these prefixes.[2]

Spelling and typographical accuracy

Because control name consistency is important, addressing this issue in the legacy UserForm context is more beneficial than addressing it after capture. The advantage becomes evident if you ever need to recapture a legacy UserForm. In that scenario, any work you performed to create consistency in the post-capture representation is lost, because re-capturing produces a new copy of the captured data.

But the case for pre-capture consistency is at least as strong for spelling and typographical accuracy with respect to elements other than control names. Consistency in these items, which include control caption properties, VBA procedure names, and messages to be displayed by code, does help to reduce maintenance costs after capture.

Layout

Many aspects of UserForm layout are more easily dealt with in MDUF than in GUFEF. Alignment, placement relative to other controls, and placement relative to the UserForm rectangle are examples. Careful specification of some attributes can safely be deferred until after capture is complete.

One option worth considering is Project!CaptureIntegerSizesAndPositions. Setting it to TRUE causes MDUF to capture sizes and positions of controls as integers, even if they’re specified to .01 twips resolution. The assumption is that non-integer attributes are present only because the designer of the UserForm had limited control of the GUFEF.

Color

Colors are also best deferred until post-capture. MDUF has a setting that causes the UCF to ignore the legacy colors and use colors you define instead.

Setting Project!CaptureControlColors to FALSE causes MDUF to ignore the color attributes of controls and UserForms. By setting the color attributes at the Project level, you can capture the UserForms, ensuring that colors are consistent across all UserForms. See “Defining colors for controls, UserForms, and projects.”

Documentation

If the system you’re capturing has accompanying documentation, preparing the system for capture might cause a divergence between the documentation and the appearance or behavior of the UserForms. The same possibility applies to help files and test scripts. If such a divergence would create problems for users, then it might be necessary to choose between updating the documentation and help files on the one hand, and curtailing the capture preparations on the other. Similarly, updating names might need to be deferred until post-capture if test scripts can’t be adjusted pre-capture.

You can limit the impact of these effects by shortening the capture period, which I would define as the time between the start of the capture process and the release of the MDUF version of the system. Shortening the capture process is possible if you employ automation for some steps. In another approach, you can defer capture preparation changes until all necessary changes have been identified. Then make all of them at one go. The approach that works for one system might not work for another. But this is an issue that might deserve attention.

[1] All the mDialogBoxes you encounter while using MDUF commands are UserForms that have been constructed with MDUF. Some were captured from versions that were created with Excel’s GUFEF.

[2] In a future release of MDUF, it will be possible to specify arbitrary (non-conflicting) three-character prefixes on a project-by-project basis.