John W. Colby
jwcolby at colbyconsulting.com
Sat Mar 13 18:35:17 CST 2004
>Objective/Question 1: How would you add a "dynamic sentence case" system
that is specific to certain controls. For instance, I have a several forms,
each form can have up to 45 text box and combos used to enter/display data.
There are 6 different "types" of information stored. One type would be
"Model and Serial Numbers", Another type would be Address..etc. Each
requiring a different sentence case. Which is user selectable in the program
settings for each of
these 6 types.
This could be handled at least two different ways (using class methodology)
and a third way using the existing function. Which is "the best" will never
be agreed upon in a room full of developers but in general you should be
analyzing the complexity of the system and if there are objects such as
recordsets, collections or other objects (in the module that does the proper
case) that need initializing.
1) Take all of the code that currently exists in a module for this proper
case widget and turn it into a class. Dim a variable in the header of the
text box class ONLY to hold an Integer ProperCaseType and another to hold a
pointer to the class (assuming that no other control type will be used for
free form data entry).
In the text box class, add a method that is passed in an Integer that tells
THIS class instance that it needs to do the proper casing and what "type" it
will be performing. In the class, as that value is passed in, initialize
the propercase class and store a pointer to it in the variable in the text
box header. Also store that ProperCaseType integer in its variable in the
text box class header.
Now in the OnExit event of the text box (in the text box class event sink of
course - WithEvents), if the ProperCaseType integer is > 0 then call the
Propercase function passing the value of the text box and returning the
value back into the text box.
That's the general idea anyway. Which event is up to you but the concept is
that you have a ProperCaseClass which you only load if you (the developer)
passes an integer value to a method of some specific text box class
instance. Now that text box class instance will propercase its data.
2) If the ProperCase code is simple (unlikely but possible) the next way
would be to simply add all of that code into the text box class directly.
Again, if the developer passes an integer ProperCase type value into a text
box class method, then the text box will use one of its events to pass the
value entered by the user to the ProperCase code and place the returning
value back to the text box.
3) And finally, just leave the ProperCase code out in a module somewhere and
call that code from the class. Everything else the same, integer
ProperCaseType passed to the specific text box class instance(s) that should
perform ProperCase behavior, but call the function out in the module rather
than inside the class or in a dedicated class.
Which is the "best". Again ask any 10 developers on this list and you will
get answers all over the place and possible even other solutions.
I tend to say that if the code is particularly complex it should be in it's
own class. If it has to instantiate recordsets, run queries or other stuff
then it DEFINITELY should be in it's own class.
If the code is simple, then it should probably just be embedded directly in
the text box class.
If the code will also be called from a query or the likes then it should
(perhaps ALSO) be left out in a module. However even here if it is complex
and particularly if it has to open recordsets and stuff, I tend to make it a
class, instantiate it in the framework's base class and write a wrapper
function.
As you start to use classes you will develop your own sense of when and why
to use classes. Generally I would build a dedicated class because then it
could be easily "hooked in" to the framework at several different levels.
If you are using a "commercial" framework (with source of course) you could
have your tied in without having to extensively modify the thing which would
make upgrading difficult. Classes are very nice for "encapsulation" of all
the code and variables required, initializing everything in Init() and
cleaning itself up in Term().
Notice that from a framework perspective, it doesn't matter which of the
three methods you use, you will still hook it in to the text box class such
that you just call a method passing in that ProperCaseType integer and the
class takes over and just does it.
Notice too that it isn't "specific to certain controls" at all. Any control
(of that type - text in this case) "knows how" to "proper case" and it's
just a matter of "turning it on" by passing in a ProperCaseType to the
specific text box class instances that need to use this functionality! THAT
is what a framework is really all about. Behaviors are NEVER "specific to
certain controls" they are instead "turned on for certain controls".
John W. Colby
www.ColbyConsulting.com
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Robert Gracie
Sent: Saturday, March 13, 2004 3:35 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Framework Discussion - Questions..
John,
I have been messing around with your last db today, and I'm trying to stay
with this. I have two questions/problems..
Objective/Question 1:
How would you add a "dynamic sentence case" system that is specific to
certain controls. For instance, I have a several forms, each form can have
up to 45 text box and combos used to enter/display data. There are 6
different "types" of information stored. One type would be "Model and Serial
Numbers", Another type would be Address..etc. Each requiring a different
sentence case. Which is user selectable in the program settings for each of
these 6 types.
Currently I'm using a procedure, which among other things passes an integer
for the "case type", along with the text from the control. Something like
the below is placed on the OnExit event on each of the control I have
programmed to be "case controlled"
Example of Old Method:
If bolMCaseY = True And Not IsNull(Me.Address1) = True Then
Me![Address1] = ProperManager(Me![Address1], iMCaseChoice)
End If
I can't seem to figure out how to "instruct" the framework which controls
are to be handled and which Case to use. I would love to get rid of all
those procedure stubs in CBF.
Objective/Question 2:
I'm trying to add an error system to the framework. Basically I want to
implement an error class that will extend the current err object with
Logging, SMTP error reporting, etc..
Unless I'm doing something wrong, you can't dim the err object WithEvents,
so that's out. I'm able to get the system to work in the form class
directly, but that's it. I would like to pass the error control to the form
passed into the form collection (and maybe into the control collection, and
handle the errors there, but I simply keep running into dead ends.... I'm
not even sure this can be done, or should be done. I think it would make
for MUCH less coding though....
I'm sure I'm going about this all wrong.....:-(
Option Compare Database
Option Explicit
Public fdclsFrm As dclsFrm
Private Err As clsErrorSystem
Private Sub Form_Open(Cancel As Integer)
Set fdclsFrm = New dclsFrm
Set Err = New clsErrorSystem
Err.Init Me
fdclsFrm.Init Me, Me
With fdclsFrm.colClasses
.item("cboCompany").clsDepObj.Add .item("cboEmployee"),
cboEmployee.Name
.item("cboCompany").clsDepObj.Add fdclsFrm, Me.Name
.item("cboCompany").Requery
End With
End Sub
Private Sub cmdClose_Click()
Dim lng As Long
On Error GoTo HandleErr
Me.Caption = "some text"
lng = "Sdf" ' causes an error
'DoCmd.Close
ExitHere:
Exit Sub
HandleErr:
Select Case Err.Number
Case Else
MsgBox Err.BuildError("frmpeopleV3.CmdClose")
End Select
End Sub
Robert Gracie
www.servicexp.com
--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com