Visual Basic Tips #9



----------------------------------------------

TipWorld - http://www.tipworld.com
The Internet's #1 Source for Computer Tips, News, and Gossip

Proudly presents:
Visual Basic

----------------------------------------------

*1. PRINTING A FORM'S DESCRIPTION                 
        
In our last tip, we told you how to view a text version of a form or 
project in a text viewer. Once the text version is in your word 
processor, you can print it. You might be interested to know that 
there's a quicker way to print a form's description. With the form 
current, choose Print from the File menu. In the Print What section, 
select the Form As Text option, then click OK. VB will send the text 
version of your form directly to the default printer.


*2. PROBLEM FORM?                 
        
If VB encounters an error while loading a form, VB will create a log 
file to report that error. Once the form is loaded, VB will display a 
message telling you that an error log file was created. That log file 
has the same name as your form, except VB uses the extension .log 
instead of .frm. For instance, if your form's name is frmEntry.frm, VB 
will name the log file frmEntry.log. To learn more about the error 
that occurred, simply view the form's log file. If you encounter an 
error during the next loading process, VB will overwrite the prior 
error record, so the log doesn't keep an historical perspective.


*3. THE ME IDENTIFIER IS MORE EFFICIENT                 
        
When you reference a form or userform in an event procedure, we 
recommend that you use the Me identifier to refer to the form. For 
instance, if you wanted a command button's Click event to display the 
active form's name, you might use a procedure similar to the 
following: 

Private Sub cmdName_Click() 
MsgBox formname.Name 
End Sub 

where formname represents the active form. 

However, the statement 

Me.Name 

is more efficient. The Me identifier restricts VB's search to the form 
that's running the code.


*4. TYPE MISMATCH                 
        
Do you hate the Type Mismatch error as much as I do? Well, any error 
is annoying, but this one seems to crop up way too often. For the most 
part, you won't see this error because you forgot to convert something 
properly--VB's pretty good at figuring out most data type assignments 
itself. When this error appears, it generally means you've made one of 
the following mistakes: 
 - You've attempted to define a variable or set a property with the 
wrong data type. For instance, you can't pass a string to a procedure 
that expects an integer. If you don't know what type of data you might 
have to accommodate, use the Variant data type. 
- You tried to pass an object to a procedure that's expecting a single 
property or value. 
- You used a module or project name where VB expected an expression. 
For instance, you can't print an object with the Debug object. 

 
These three mistakes are probably the most common reasons VB returns 
the Type Mismatch error. Fortunately, all three errors are relatively 
easy to find and resolve.


*5. A DAO DUH MOMENT                 
        
Normally, we try to reclaim resources as soon as possible by closing 
objects we're done with and setting object variables to Nothing. Have 
you ever tried to delete a temporary table or query that you know 
exists and received an error? There are several reasons this might 
happen, but one you might not consider is the order of your 
statements. You see, if you're working with an open recordset that's 
based on that temporary table or query, you can't delete the data 
source until you close the recordset. This situation is one case where 
you'll just have to wait until you close the recordset. Only then can 
you delete the temporary data source.


*6. REMOVING A FORM OBJECT                 
        
You probably know that you should unload a form to free up resources 
once you're done with it. However, if you're using a collection to 
track forms, do you know how to release those resources? Unloading the 
form just isn't enough. Unloading the form won't remove the reference 
from the collection. You see, as long as the reference to the form 
exists, you can't reclaim that memory. After you unload the form, use 
the collection's Remove method to delete the form's object reference 
from the collection. Only then will you reclaim that memory.


*7. NO SECRET CODE IN THOSE COMMENTS                 
        
All developers know they're supposed to comment their code, and most 
do. Unfortunately, some don't do a very good job. Too often developers 
want to take shortcuts with their code and write phrases and 
abbreviations. Do yourself a favor and use proper English in your 
comments. In addition, make your comments whole sentences. As a final 
thought, avoid abbreviations unless they're universally known. If you 
end up revamping the application a few months or a year down the road, 
you'll be glad you took the extra effort with your comments.


*8. IMAGE VERSUS PICTURE BOX                 
        
You can speed up your application by reducing the size of your 
application. Easier said than done, right? There are many tricks you 
can use to reduce the size of an application, and here's an easy one. 
Don't overuse the Picture Box control. That control has special 
qualities: It can contain other controls, and it also provides 
graphics methods. Consequently, the Picture Box control also requires 
more memory. Whenever possible, use the Image control for simpler 
tasks such as displaying pictures and responding to Click events and 
mouse actions. The less complicated the task, the fewer bells and 
whistles your control needs. By following this simple rule, you'll 
save on resources.


*9. WORKING WITH ICONS AND BITMAPS                 
        
If you don't want to use text to convey a control or form's purpose, 
you can always use an icon or bitmap. In fact, this is very common, 
and there are plenty of both to choose from. However, you might want 
to follow these two simple rules when you consider substituting text 
with either: 
 - Make sure the icon or bitmap you choose is a standard. Anything but 
a universally known standard may fail to get your point across. 
- Avoid using icons or bitmaps that include text. For one thing, 
what's the point? For another, they take more time to draw.


*10. UNIVERSAL CURRENCY                 
        
When referring to currency in your code, avoid strings. For instance, 
it might be tempting to use the following statement: 

strAmount = "$999.99" 

If you use this statement, there's no way to control the way your 
application displays this currency amount, which means that it has no 
international appeal. Even though your application may never see the 
international market, it's just not a good idea to hard-code formats 
unless you absolutely must. Fortunately, you can avoid the problem 
altogether if you use the CCur function in the form 

strAmount = CCur(amount) 

The CCur function will provide internationally aware conversions from 
any other data type to Currency.
