Properties: Not Just For Classes Anymore
Posted: 2002-06-01
By: ArchiveBot
Viewed: 103
Filed Under:
No attachments for this post
Shows a methodology for drastically reducing the amount of time needed to develop "similar but not quite" forms for a type of task.
Original Author: Devin Watson
Code
Properties: Not Just For Classes Anymore Often times, I've run into a situation where I say to myself "I However, I did find a unique solution, whilst developing something Surprisingly, VB didn't complain one bit, and I was able to reduce Start up Visual Basic with a Standard EXE project. In the project, Dim mstrTable As String You'll pop into the new property's code, just as if you typed it in
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.)
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?
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.
add another, blank form. Inside this new form, open up the Code Editor window. In the
General Declarations area, type the following:
And then type:
Public Property Let Table(strTable As String)
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!
Comments on this post
No comments have been added for this post.
You must be logged in to make a comment.