• Home
 · 
• Object Oriented Programming (OOP)
 · 
• Properties: Not Just For Classes Anymore

Properties: Not Just For Classes Anymore

Shows a methodology for drastically reducing the amount of time needed to develop "similar but not quite" forms for a type of task.

Rate Properties: Not Just For Classes Anymore

• 1
• 2
• 3
• 4
• 5

(6(6 Vote))

Properties: Not Just For Classes Anymore
Often times, I've run into a situation where I say to myself "I
wish I could've reused the same form for this purpose." Early on, it was just that; I
would copy a form's code and controls over to a new one, adjusting as necessary. Of
course, this led to bloated executables and more spaghetti code than I care to remember
(it still makes me shudder to think about it.)
However, I did find a unique solution, whilst developing something
else entirely: a class module. When developing the properties of a particular class, I
wondered if it would be possible to actually do the same to a form. In essence, take a
standard VB form and then add my own custom properties. I had done it before using custom
methods, but would VB throw up on me for doing something I shouldn't?
Surprisingly, VB didn't complain one bit, and I was able to reduce
four forms that were exactly the same except for a few "under-the-hood" changes.
These changes were easily be implemented as properties, and what would have taken me
several hours to create and debug, now only took 15 minutes. In the rest of this article,
I'll discuss and show how this methodology can be used to reduce development time even
more, using a simple but powerful example.
Start up Visual Basic with a Standard EXE project. In the project,
add another, blank form. Inside this new form, open up the Code Editor window. In the
General Declarations area, type the following:
Dim mstrTable As String



And then type:



Public Property Let Table(strTable As String)
You'll pop into the new property's code, just as if you typed it in
a class module. Inside this new property, type the following:



Public Property Let Table(strTable As String)



mstrTable = Trim(strTable)



If Not IsValid(mstrTable) Then

     Err.Raise 30000, "Data Table Editor", "Table name
appears to be invalid."

     Exit Property

End If



Me.Caption = "Table Editor - " & mstrTable

GetTableItems mstrTable

Me.Visible = True

Me.ZOrder 0



End Property



In the example above, setting the new Table property for the form performs several
functions. First, it removes leading and trailing spaces, then checks to see if the name
given is, in fact valid ( the function IsValid is not shown here, but rather used to point
out that your validation can remain within a form). If the table name is not valid, then
an error is raised. This way, the calling form would have something as follows:



On Local Error Resume Next



frmEdit.Table = "monkeys"

If Err.Number = 30000 Then Exit Sub



However, if the table name given is valid, then it goes on to change the caption to
reflect the new table name, and the items from that table are retrieved using another
private subroutine called GetTableItems. Once that has completed, then the form is made
visible, and moved to the forefront of the screen. 



Caveats



Using this method can save time by reducing the amount of code you type over and over.
However, it is advisable to use the Load statement to cache the form in memory during
program load time, so as to avoid any "Object or With Variable Not Set" errors.



Is This The End Of Zombie Shakespeare?



Nope. You can use this method to infinitely extend a form. Just remember to make sure you
generalize it enough so that it encompasses the job you want to do, and that you cache it
up in memory during program load. 



Happy Programming!