A little class

  • Thread starter Thread starter George
  • Start date Start date
G

George

I'm new to classes, and I'm not entirely sure I know
whether this is a proper application:

Because almost every person-oriented record contains Name,
Address, Email, Phone Number, does it make sense to create
a single, consistent maintenance screen, called
frmContacts, and have a class that maintains it?
I'm thinking:

Dim objSubcontractor as Contact
With objSubcontractor
.table = "tblSubcontractor"
.Name = "tblSubcontractor.Name"
.Phone1 = tblSubcontractor.[Business Phone]"
.Phone2 = "tblSubcontractor.[Home Phone]"
.Address = tblSubcontractor.[Business Address]"
End with
OpenForm "frmContacts"

Does this sound like a strategy to persure?
 
It might be...but then you might accomplish the same thing by changing the
recordsource for the form. For example, if you have a tblCustomers and
tblVendors and the fields are for the most part identical, you could just
change the recordsource instead of having 2 forms. A form is also a class.

Think of a class as some abstract "thing". The "thing" has certain
attributes (properties) and it may also allow you to tell it to do stuff
(methods) and/or it may respond to your instructions (events).

Classes are also a good way to ensure that something is accomplished within
a defined context and will not be affected by some other part of your
program...i.e, you instantiate a widget object (class) from within one form,
and another widget object (class) within another form...while the widgets
are structurally the same, their properties/data may be completely
different...but more importantly neither form can manipulate data in the
other's widget if the widget is declared private by the form. You might use
this behavior to write a validation procedure that could be used by any form
for example.

Classes can also serve as a data container. For example, you might have a
form with several subforms where you want to share a set of information not
defined within the form itself...maybe you need to pass status information
or results between the various subforms. You could have a class declared
within the parent form and a Public property or function to allow each
subform to get a copy of the class.

I write a lot of classes, mostly to encapsulate a set of
functionality...i.e., to open the common file dialog, or to link tables, or
perform a set of operations. Being abstract, classes are basically
whatever you want them to be...but they can also be difficult to define in a
useful and logical manner.
 
Recall: I'm trying to learn how to use a class:
At your suggestion, I've reconsidered the application and
I've created a class, clsContactName, which I can use as
follows:

Function Test()
Dim oSubcontractorName As clsContactName
Set oSubcontractorName = New clsContactName
With oSubcontractorName
.ParseName "Bush, President George Herbert Walker III"
Debug.Print "Title: "; .Title
Debug.Print "FirstName: "; .FirstName
Debug.Print "MiddleName: "; .MiddleName
Debug.Print "LastName: "; .LastName
Debug.Print "Suffix: "; .Suffix
End With
Set oSubcontractorName = Nothing
End Function

So, a couple of follow-on questions:
1) How should I implement a CheckFullName form?
a) Can I / Should I put a form into a class?
b) Can I establish a generic CheckFullName
form that refers to the instance?
2) I have some code, a standard module, that calls
the common OpenFile Dialog; how can I (should I?)
encapsulate that into a class module?

Thank you very much for your help.
George
-----Original Message-----
It might be...but then you might accomplish the same thing by changing the
recordsource for the form. For example, if you have a tblCustomers and
tblVendors and the fields are for the most part identical, you could just
change the recordsource instead of having 2 forms. A form is also a class.

Think of a class as some abstract "thing". The "thing" has certain
attributes (properties) and it may also allow you to tell it to do stuff
(methods) and/or it may respond to your instructions (events).

Classes are also a good way to ensure that something is accomplished within
a defined context and will not be affected by some other part of your
program...i.e, you instantiate a widget object (class) from within one form,
and another widget object (class) within another form...while the widgets
are structurally the same, their properties/data may be completely
different...but more importantly neither form can manipulate data in the
other's widget if the widget is declared private by the form. You might use
this behavior to write a validation procedure that could be used by any form
for example.

Classes can also serve as a data container. For example, you might have a
form with several subforms where you want to share a set of information not
defined within the form itself...maybe you need to pass status information
or results between the various subforms. You could have a class declared
within the parent form and a Public property or function to allow each
subform to get a copy of the class.

I write a lot of classes, mostly to encapsulate a set of
functionality...i.e., to open the common file dialog, or to link tables, or
perform a set of operations. Being abstract, classes are basically
whatever you want them to be...but they can also be difficult to define in a
useful and logical manner.
--
Paul Overway
Logico Solutions
http://www.logico-solutions.com


I'm new to classes, and I'm not entirely sure I know
whether this is a proper application:

Because almost every person-oriented record contains Name,
Address, Email, Phone Number, does it make sense to create
a single, consistent maintenance screen, called
frmContacts, and have a class that maintains it?
I'm thinking:

Dim objSubcontractor as Contact
With objSubcontractor
.table = "tblSubcontractor"
.Name = "tblSubcontractor.Name"
.Phone1 = tblSubcontractor.[Business Phone]"
.Phone2 = "tblSubcontractor.[Home Phone]"
.Address = tblSubcontractor.[Business Address]"
End with
OpenForm "frmContacts"

Does this sound like a strategy to persure?
Click to expand...


.
Click to expand...
 
See comments in-line...

--
Paul Overway
Logico Solutions
http://www.logico-solutions.com


George said:
Recall: I'm trying to learn how to use a class:
At your suggestion, I've reconsidered the application and
I've created a class, clsContactName, which I can use as
follows:

Function Test()
Dim oSubcontractorName As clsContactName
Set oSubcontractorName = New clsContactName
With oSubcontractorName
.ParseName "Bush, President George Herbert Walker III"
Debug.Print "Title: "; .Title
Debug.Print "FirstName: "; .FirstName
Debug.Print "MiddleName: "; .MiddleName
Debug.Print "LastName: "; .LastName
Debug.Print "Suffix: "; .Suffix
End With
Set oSubcontractorName = Nothing
End Function

So, a couple of follow-on questions:
1) How should I implement a CheckFullName form?
a) Can I / Should I put a form into a class?
b) Can I establish a generic CheckFullName
form that refers to the instance?
Click to expand...

You'll have to clarify what the CheckFullName form is for. I'm assuming
you'd use it to prompt the users if there were missing/invalid entries. So,
I'm guessing you'll do some type of validation within your class, and then
if the data is invalid show the form with the data, and prompt the user for
corrections. If you need multiple instances of a form open (or need to
allow for that possibility), you won't be able to use
Docmd.OpenForm...you'll have to instantiate the form and poll it for
completion...once you know the user has completed the form corrections, you
can go on with the rest of your business.

2) I have some code, a standard module, that calls
the common OpenFile Dialog; how can I (should I?)
encapsulate that into a class module?
Click to expand...

You might create a class for this purpose and have the following properties
and methods:

Mode: Property (i.e., Save, Open)
AddFilter: Method (use to add different
extensions/filespecs to filter by)
Show: Method (used to show the dialog and return the
filepath)
Options: Property (use to specify various flags, i.e.,
ReadOnly, Overwrite, etc.)

....and you'd probably have some public enums setup for the options property.

This is just one idea, there are a variety of ways to go about it. You
might look at the interface for comdlg32.ocx as an example, because that is
what you're really trying to duplicate...but your class will have the
advantage of not requiring a reference to an OCX.
Thank you very much for your help.
George
-----Original Message-----
It might be...but then you might accomplish the same thing by changing the
recordsource for the form. For example, if you have a tblCustomers and
tblVendors and the fields are for the most part identical, you could just
change the recordsource instead of having 2 forms. A form is also a class.

Think of a class as some abstract "thing". The "thing" has certain
attributes (properties) and it may also allow you to tell it to do stuff
(methods) and/or it may respond to your instructions (events).

Classes are also a good way to ensure that something is accomplished within
a defined context and will not be affected by some other part of your
program...i.e, you instantiate a widget object (class) from within one form,
and another widget object (class) within another form...while the widgets
are structurally the same, their properties/data may be completely
different...but more importantly neither form can manipulate data in the
other's widget if the widget is declared private by the form. You might use
this behavior to write a validation procedure that could be used by any form
for example.

Classes can also serve as a data container. For example, you might have a
form with several subforms where you want to share a set of information not
defined within the form itself...maybe you need to pass status information
or results between the various subforms. You could have a class declared
within the parent form and a Public property or function to allow each
subform to get a copy of the class.

I write a lot of classes, mostly to encapsulate a set of
functionality...i.e., to open the common file dialog, or to link tables, or
perform a set of operations. Being abstract, classes are basically
whatever you want them to be...but they can also be difficult to define in a
useful and logical manner.
--
Paul Overway
Logico Solutions
http://www.logico-solutions.com


I'm new to classes, and I'm not entirely sure I know
whether this is a proper application:

Because almost every person-oriented record contains Name,
Address, Email, Phone Number, does it make sense to create
a single, consistent maintenance screen, called
frmContacts, and have a class that maintains it?
I'm thinking:

Dim objSubcontractor as Contact
With objSubcontractor
.table = "tblSubcontractor"
.Name = "tblSubcontractor.Name"
.Phone1 = tblSubcontractor.[Business Phone]"
.Phone2 = "tblSubcontractor.[Home Phone]"
.Address = tblSubcontractor.[Business Address]"
End with
OpenForm "frmContacts"

Does this sound like a strategy to persure?
Click to expand...


.
Click to expand...
Click to expand...
 
At your suggestion I now have the following:

Private Sub butFullName_Click()
On Error GoTo Err_butFullName_Click
Dim oFullName As New Form_frm_UCheckFullName
With oFullName
.FullName = "" & Me.LAST_FIRST_NAME
.ParseFullName
.txtFirstName = .FirstName
.txtLastName = .LastName
.txtMiddleName = .MiddleName
.cbxTitle = .Title
.cbxSuffix = .Suffix
End With
--
' The following works but gives me "default" classs (Not my data)
Dim stDocName As String
Dim stLinkCriteria As String
stDocName = "frm_UCheckFullName"
DoCmd.OpenForm stDocName, , , stLinkCriteria
'--
'This gives me my instance, but it does not stop
oFullName.SetFocus

Exit_butFullName_Click:
Exit Sub

How can I get it to stop here for data entry?


Paul Overway said:
See comments in-line...

--
Paul Overway
Logico Solutions
http://www.logico-solutions.com


George said:
Recall: I'm trying to learn how to use a class:
At your suggestion, I've reconsidered the application and
I've created a class, clsContactName, which I can use as
follows:

Function Test()
Dim oSubcontractorName As clsContactName
Set oSubcontractorName = New clsContactName
With oSubcontractorName
.ParseName "Bush, President George Herbert Walker III"
Debug.Print "Title: "; .Title
Debug.Print "FirstName: "; .FirstName
Debug.Print "MiddleName: "; .MiddleName
Debug.Print "LastName: "; .LastName
Debug.Print "Suffix: "; .Suffix
End With
Set oSubcontractorName = Nothing
End Function

So, a couple of follow-on questions:
1) How should I implement a CheckFullName form?
a) Can I / Should I put a form into a class?
b) Can I establish a generic CheckFullName
form that refers to the instance?
Click to expand...

You'll have to clarify what the CheckFullName form is for. I'm assuming
you'd use it to prompt the users if there were missing/invalid entries. So,
I'm guessing you'll do some type of validation within your class, and then
if the data is invalid show the form with the data, and prompt the user for
corrections. If you need multiple instances of a form open (or need to
allow for that possibility), you won't be able to use
Docmd.OpenForm...you'll have to instantiate the form and poll it for
completion...once you know the user has completed the form corrections, you
can go on with the rest of your business.

2) I have some code, a standard module, that calls
the common OpenFile Dialog; how can I (should I?)
encapsulate that into a class module?
Click to expand...

You might create a class for this purpose and have the following properties
and methods:

Mode: Property (i.e., Save, Open)
AddFilter: Method (use to add different
extensions/filespecs to filter by)
Show: Method (used to show the dialog and return the
filepath)
Options: Property (use to specify various flags, i.e.,
ReadOnly, Overwrite, etc.)

....and you'd probably have some public enums setup for the options property.

This is just one idea, there are a variety of ways to go about it. You
might look at the interface for comdlg32.ocx as an example, because that is
what you're really trying to duplicate...but your class will have the
advantage of not requiring a reference to an OCX.
Thank you very much for your help.
George
-----Original Message-----
It might be...but then you might accomplish the same thing by changing the
recordsource for the form. For example, if you have a tblCustomers and
tblVendors and the fields are for the most part identical, you could just
change the recordsource instead of having 2 forms. A form is also a class.

Think of a class as some abstract "thing". The "thing" has certain
attributes (properties) and it may also allow you to tell it to do stuff
(methods) and/or it may respond to your instructions (events).

Classes are also a good way to ensure that something is accomplished within
a defined context and will not be affected by some other part of your
program...i.e, you instantiate a widget object (class) from within one form,
and another widget object (class) within another form...while the widgets
are structurally the same, their properties/data may be completely
different...but more importantly neither form can manipulate data in the
other's widget if the widget is declared private by the form. You might use
this behavior to write a validation procedure that could be used by any form
for example.

Classes can also serve as a data container. For example, you might have a
form with several subforms where you want to share a set of information not
defined within the form itself...maybe you need to pass status information
or results between the various subforms. You could have a class declared
within the parent form and a Public property or function to allow each
subform to get a copy of the class.

I write a lot of classes, mostly to encapsulate a set of
functionality...i.e., to open the common file dialog, or to link tables, or
perform a set of operations. Being abstract, classes are basically
whatever you want them to be...but they can also be difficult to define in a
useful and logical manner.
--
Paul Overway
Logico Solutions
http://www.logico-solutions.com


I'm new to classes, and I'm not entirely sure I know
whether this is a proper application:

Because almost every person-oriented record contains Name,
Address, Email, Phone Number, does it make sense to create
a single, consistent maintenance screen, called
frmContacts, and have a class that maintains it?
I'm thinking:

Dim objSubcontractor as Contact
With objSubcontractor
.table = "tblSubcontractor"
.Name = "tblSubcontractor.Name"
.Phone1 = tblSubcontractor.[Business Phone]"
.Phone2 = "tblSubcontractor.[Home Phone]"
.Address = tblSubcontractor.[Business Address]"
End with
OpenForm "frmContacts"

Does this sound like a strategy to persure?




.
Click to expand...
Click to expand...
Click to expand...
 
Back
Top