Navigation:  Articles > Aug-2002 >

Review - FMS Total Visual Code Tools 2002-2000

Previous pageReturn to chapter overviewNext page

Danny J. Lesandrini        

If you’ve never been good about coding standards, or your good intentions are sometimes sacrificed when you’re working in crunch mode, then you owe it to yourself to check out Total Visual Code Tools 2002, a great set of coding tools by FMS. Here, Danny Lesandrini walks you through an introduction.

If memory serves me, it was VBITS San Francisco 2001 where I heard a VB old-timer talk about how he and his fellow trailblazers unwittingly set coding standards for future generations of developers. Their personal preference for naming conventions and code formatting became the de facto standard for self-taught newbies who read their books and magazine articles. Now, I don’t mean to imply that there’s anything wrong with their example, but by the same token, there’s nothing wrong with determining and applying your own standards.

That’s what Total Visual Code Tools 2002 is all about: taking control of your code, applying your standards, and simplifying the process.

Note from Garry.  I am using FMS Total Visual Code tools for Access 2007. It also works fine in Access 2003 and in vb6 because the licence allows you to switch between VB environments. For Pricing on the latest versions of FMS, see our FMS Software resale page

I used to be one of those self-taught newbies. I clearly remember studying the code generated by Access wizards and emulating that in the methods that I wrote. For example, the Access 97 wizard generated this code for running Excel from a button click in Access:

Private Sub cmdRunExcel_Click() 
 
On Error GoTo Err_cmdRunExcel_Click
 

  Dim oApp As Object

  Set oApp = CreateObject("Excel.Application")     
  oApp.Visible = True     
  'Only XL 97 supports UserControl Property     
  On Error Resume Next     
 

   oApp.UserControl = True
 

Exit_cmdRunExcel_Click:     
  Exit Sub

Err_cmdRunExcel_Click:     
  MsgBox Err.Description     
  Resume Exit_cmdRunExcel_Click

End Sub
 

Notice that the On Error instruction is the first line of code and isn’t indented, while the variable declaration follows and is indented. To this day, that’s my style. This example also demonstrates the wizard’s naming convention: The Excel generic object is prefixedwith the letter “o.” Not so strangely, my typical error handler looks pretty much like what you see here too. “Not that there’s anything wrong with that,” as Jerry Seinfeld once said, but maybe it’s time for a change.

What is Total Visual Code Tools?

When was the last time you gave thought to the naming conventions you use? Do all of your methods contain regular error-handling code? What about comment blocks in method headers? What if you had the power to revisit all your existing code, reformatting it and standardizing naming conventions, comments, and error handling? Would you also like a set of easy-to implement procedure templates for writing the shell for tediously similar code? Moving beyond coding standards, a tool for parsing long strings, such as SQL statements, into a more readable format for embedding in modules? All this and more is available in Total Visual Code Tools 2002.

If you have the developer version of Access 2000 or 2002, then you’ve probably seen the Microsoft equivalents of these tools (for example, the String Editor and Code Commenter dialog boxes). Even the standard version of Access has always included the Add Procedure dialog box, available from the Insert menu. These tools are useful, but they’re primitive compared to what FMS delivers.

Consider, for example, the difference between creating a custom property using the FMS New Property Builder, as opposed to the Microsoft Add Procedure dialog. In Figure 1 (on page 18), you can see that you have much more control over the output when using Total Visual Code Tools compared to the Microsoft Add Procedure dialog. And, while the Microsoft dialog produces four lines of code, the FMS tool generates 37 lines, which includes comments and error handling.

I can’t illustrate all the differences, but you see a similar outcome if you compare the Microsoft String Editor with the FMS Text/SQL Builder—or any of the various code-commenting tools. You can get an idea of the comprehensive nature of the toolkit by looking at the Standards option dialog, shown in Figure 2, that controls how comments are generated. Just about everything you could imagine is configurable: comment location, indentation, and the text to be inserted. Different templates can be created for procedures, properties, and new routines vs. templates for cleaning of existing code.
 
As you can see in Figure 2, you can also sets tandards for error-handling code and naming conventions. For example, you may prefer to prefix strings with an “s” instead of the common “str.” Once you settle on standards, they’ll be used when you use the FMS tools for inserting new code templates and when running cleanup against existing code. Your standards can then be saved to a file and shared with team members who also use FMS Total Visual Code Tools. This ensures that all developer-generated code will have a similar look and feel.
 
 
200208_DL_FMS1
Figure 1. FMS New Property Builder vs. the Microsoft Access Add Procedure dialog box.
 
200208_DL_FMS2
Figure 2. Set coding standards according to your pleasure.

 

 

But wait—there’s more

While it was great of the Microsoft Access development team to include the native tools, it’s clear that they left the door open for companies like FMS to assist the developer community with some cool utilities. In addition to what I’ve already described, Total Visual Code Tools 2002 includes utilities to insert code for message boxes, Select Case statements, and the code to return an ADO or DAO recordset. Is it rocket science?

No, but it sure is convenient. For example, look at this code generated by the ADO Recordset Builder:

Dim cnn As ADODB.Connection 
Dim rst As ADODB.Recordset 
Dim strSQL As String

Set cnn = New ADODB.Connection 
Set rst = New ADODB.Recordset

 

strSQL = "SELECT * " & _          "FROM tblTime" 
cnn.Open "DSN=TM;APP=Microsoft Office XP;" & _    ";DATABASE=TM;Trusted_Connection=Yes" 
rst.Open strSQL, cnn
 

Do While Not rst.EOF     
  Debug.Print rst.Fields("TimeEntryID")
  Debug.Print rst.Fields("ConcurrencyID")
  Debug.Print rst.Fields("UserID")     
  Debug.Print rst.Fields("TaskID")     
  Debug.Print rst.Fields("TaskUserDate")     
  Debug.Print rst.Fields("TaskUserHours")     
  Debug.Print rst.Fields("LastUpdated")   
  rst.MoveNext 
Loop

rst.Close 
Set rst = Nothing 
cnn.Close 
Set cnn = Nothing

As I said before, all of these utilities are nice, but I’d have to say that the pièce de résistance of the package would have to be the Code Delivery utility. The idea is simple and two-fold. First, the Code Delivery utility adds line numbers to your code so that you can enable line identification in error messages. When users report an error, you can more easily locate the exact entry point of the error. Of course, you can add line numbers by hand, but if you choose to do that without some sort of automation tool, it’s a strong indication that you’ve been coding too long and you need to get a life. This feature alone could pay for Total Visual Code Tools 2002 by speeding up and simplifying debugging errors in production code.

The second reason to use the Code Delivery utility is to obfuscate your code. There are some instances where you can’t simply lock your database by converting it into an MDE. For example, I once created an Access Add-In for distribution and tried to lock its code. Unfortunately, after compiling it as an MDE, some of the functionality was disabled. I ended up delivering the Add-In with the code completely exposed. Though the Code Delivery tool doesn’t lock your modules, it does convert readable code into script that’s difficult to follow (see Figure 3).

As Figure 3 shows, the Code Delivery tool removes comments and also scrambles variable names. Blank lines are removed, as is all indentation. The tool also removes all Stop statements and debug code. If you want to leave some comments in your code, FMS has included a way to prefix comments with an escape character that will allow comments to remain. Like the rest of Total Visual Code Tools 2002, the tool is both powerful and flexible.

 

 

200208_DL_FMS3

Figure 3. Before and after results of using the FMS Code Delivery utility.

 

Code Tools to the rescue

If you haven’t already figured it out, I’m a fan of this product. As a rule, I like third-party tools that provide a tangible return on investment, and Total Visual CodeTools 2002 fits the bill. At the single license price of $199, this tool will easily pay for itself in the first year of use. For those of you who are both Access and Visual Basic developers, it’s a double pay-off: The version that works with both Access and Visual Basic sells for $299 for a single user. Same great tools in either development environment. Who could ask for more?
 
ad8_468x120
For Pricing on the latest versions see Garry's FMS Software resale page

 

Other Related Pages

 
FMS Total Access Analyzer 2000

Review ~ FMS Access Speller 2000+