Class Objects

[Tim Hunter]

I am using Access 2003 under WinXP.
I currently support a huge Excel Wokbook that is a maintenance
nightmare. There are about 15 worksheets each with lots of
formulas...Anyway I am thinking of converting this application to an
Access solution and specifically using Class Objects. I am comfortable
with Access but I have never worked with creating Classes. Finally my
question. I am thinking of creating one Class Form Object to match one
worksheet and then create instances of that object to accomplish the
remaining forms. Am I on the right track? I haven't worked out the logic
yet as I am still trying to design this application. My thoughts are
that when a change is requested, i will change the original object and
the instances will carry those changes forward.

TIA

Tim Hunter

*** Sent via Developersdex http://www.developersdex.com ***

[Larry Linson]

"Tim Hunter" <th*****@rochester.rr.comwrote in message
news:45***********************@news.qwest.net...

>I am using Access 2003 under WinXP.
I currently support a huge Excel Wokbook that is a maintenance
nightmare. There are about 15 worksheets each with lots of
formulas...Anyway I am thinking of converting this application to an
Access solution and specifically using Class Objects. I am comfortable
with Access but I have never worked with creating Classes. Finally my
question. I am thinking of creating one Class Form Object to match one
worksheet and then create instances of that object to accomplish the
remaining forms. Am I on the right track? I haven't worked out the logic
yet as I am still trying to design this application. My thoughts are
that when a change is requested, i will change the original object and
the instances will carry those changes forward.

I'm not at all sure you are on the right track... Forms are objects, and
Form modules are the class modules associated with the Form. If you have
hopes that Access is just going to be Excel on steroids to handle workbooks
that are too much for Excel, you are going to be sadly disappointed. And,
that is something of the drift I got from your post.

I don't think you are going to be able to use Class objects to make Access
tables and forms into "proxy Excel Workbooks", not easily, at least. And,
that would be particularly true if you, as appears to be the case, are not
an experienced object-oriented developer.

My suggestion would be that you invest some time and effort in learning what
a database is (as opposed to a spreadsheet), what Access is and how it
works, and then decide whether Access would be a good software tool to meet
the business requirements of your data and processing needs.

Larry Linson
Microsoft Access MVP

[Lyle Fairfield]

Tim Hunter <th*****@rochester.rr.comwrote in
news:45***********************@news.qwest.net:

I am using Access 2003 under WinXP.
I currently support a huge Excel Wokbook that is a maintenance
nightmare. There are about 15 worksheets each with lots of
formulas...Anyway I am thinking of converting this application to an
Access solution and specifically using Class Objects. I am comfortable
with Access but I have never worked with creating Classes. Finally my
question. I am thinking of creating one Class Form Object to match one
worksheet and then create instances of that object to accomplish the
remaining forms. Am I on the right track? I haven't worked out the
logic yet as I am still trying to design this application. My thoughts
are that when a change is requested, i will change the original object
and the instances will carry those changes forward.

You could create a form. A form is like a class but with two
differences:

If it has a module, or if its HasModule property is set to True, its
default instance is immediately available with no dimming or setting
required using the syntax Form_NameofForm and all its public properties,
child objects and procedures are available as Form_NameofForm.

It has its own interface, that is it can be and usually is visible.

Use of the syntax Form_NameofForm opens the default instance of the
form. It does not close automatically and must be closed explicitly, if
that is desired. But not closing it will not result in ghosts; it will
close automatically on application close.

Multiple instances of a form can be effected as:

Dim MyBunchofSpreadSheetForms(0 to 5) as Form_MySpreadSheet

For z = 0 to 5
Set MyBunchofSpreadSheetForms(z) = New Form_MySpreadSheet
Next z

I believe this will accomplish what you describe.

Are you on the right track? A form is not a spreadsheet. What you
suggest is not a common solution. It could be more effective to return
to the original purpose of the spreadsheet and to analyse, brain storm,
test hypothesize or whatever about the best feasible solution. This
process can be crippled if it is subject to the notion that it must
emulate the spreadsheets used, apparently not so successfully,
previously.



--
lyle fairfield

[Tim Hunter]

Well I'm not trying to make Access work like a workbook but that said, i
agree with you. I need to develop skills in Object Oriented programming
before i tackle anything like this. At first i thought it might be a
good opportunity to satisfy a user request and jump into OOP at the same
time. I believe the application can be written in plain old fashioned
Access and still meet my objectives of reducing the maintenance
nightmare.
Thank you very much for your reply..

Tim Hunter

*** Sent via Developersdex http://www.developersdex.com ***

[David W. Fenton]

"Larry Linson" <bo*****@localhost.notwrote in
news:MzEph.16053$AM4.15982@trnddc07:

My suggestion would be that you invest some time and effort in
learning what a database is (as opposed to a spreadsheet), what
Access is and how it works, and then decide whether Access would
be a good software tool to meet the business requirements of your
data and processing needs.

I agree with Larry's reading of the situation and second his advice.
Import your spreadsheets into Access. Use the point-and-click tools
to create forms and reports from the spreadsheets as you imported
them. Learn the basics, and only then start thinking about how to
make it better. You won't get anywhere if you don't know how to use
Access.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

Tim Hunter <th*****@rochester.rr.comwrote in
news:45***********************@news.qwest.net:

Well I'm not trying to make Access work like a workbook but that
said, i agree with you. I need to develop skills in Object
Oriented programming before i tackle anything like this. At first
i thought it might be a good opportunity to satisfy a user request
and jump into OOP at the same time. I believe the application can
be written in plain old fashioned Access and still meet my
objectives of reducing the maintenance nightmare.

I don't see any role for standalone class modules. But form class
modules, yes, of course.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

Tim Hunter <th*****@rochester.rr.comwrote in
news:45***********************@news.qwest.net:

Well I'm not trying to make Access work like a workbook but that
said, i agree with you. I need to develop skills in Object
Oriented programming before i tackle anything like this. At first
i thought it might be a good opportunity to satisfy a user request
and jump into OOP at the same time. I believe the application can
be written in plain old fashioned Access and still meet my
objectives of reducing the maintenance nightmare.

Oh, and Access/VBA is *not* a good platform for learning OOP, as
it's simply not really object-oriented at all, at least not in the
way the term OOP is generally used when discussing programming
languages.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/