Page 1 of 3 123 LastLast
Results 1 to 15 of 37
  1. #1
    Join Date
    Feb 2007
    Posts
    348

    Unanswered: VBA using Clases

    I think this belongs here as it is related specifically to using VBA in Access.
    as I understand it, in real VB you have to use classes.

    How many of you use classes in VBA in access. it seems like the classes mimic functions that already exist through the use of tables, at least from what little I have seen so far. I'm working through Wrox Access 2003 for beginners and the example is a Class for Car (it's a DB for a car dealer). It seems like all the class allows me to do is reference a datatype carID which doesn't seem different that a attribute carID for the table car.

    i may just need to be patient, I just thought i would see how you all use it.

  2. #2
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    I did a few projects with classes. They have some advantages such as defining attributes of an ojbect. It was more of a learning phase for me than anything. I don't use them now much because I haven't found a real need to utilize them. But I guess I could find a need for them if I put some thought to it. I've lived without them though.

    In regards to how I used them. I used a class defining a customer object. It was kind of a neat project where I had different attributes for a specific customer. I can't remember all the details (it was a few years back) but it got rather complex. I redid the project again without using classes.
    Last edited by pkstormy; 06-16-07 at 23:15.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  3. #3
    Join Date
    Feb 2007
    Posts
    348
    Gotcha, sounda about how I expected although I'll be interested to hear form disenters (sp?). It seems like most of the functional stuff, methods and that sort, are already well under control with the built in programming of access.

    Again, I realize that if I was doing "real" databases and "real" programming, it may be a different case. I just don't want anyone to think I am bashing classes as a whole or anything.

  4. #4
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    The big difference in programming for me was when I started designing unbound forms and utilizing functions to a great extent. I had a database with about 2 million customers and it needed to be accessed quickly through citrix and external users. Utilizing unbound forms and functions to read and write customers made the forms fly!! I used SQL Server as a backend and I designed some triggers and stored procedures to centralize some of the coding.

    I don't design every MS Access database this way (it takes a lot of time to design unbound forms) but if speed is a necessity and there are a lot of external users, I do consider it. I guess if I utilized classes more, I could have cut down some of the programming code.

    Personally, I'd focus my time on learning how to design and utilize the power of some good functions. I can't tell you how often I see programmers spend all this time writing all this fancy code but their db structure and form designs are crap! I know of several of them which were developed by Computer companies (who send their developers to a 2 week course.) It bugs me to an extent because these companies get rich off of their developers learning at the customer's expense! They spend a year or two developing the program and by the time they're done, the program is out-dated and needs to be changed.

    I won't mention any names, but I had to deal with this software developing company once who had a developer which designed one of our databases. The program needed to construct total energy savings. The first I thing I noticed was the developer had no date field for EACH energy saving item a customer bought (it wasn't a summarization/data warehouse database). I mentioned this to him and he came back a week later with a TEXT field which held values such as January 23, February 20, etc..and a seperate TEXT field for the year. When I asked him how I was supposed to construct monthly/yearly totals, his reply was "Simple - you just add: Like "January" & * or Like "February" & * or Like "March" & *, etc... for the TEXT (date represented) field and Like "2002", for the Year field to the query. And if you need to add another month, simply edit the query and add the like statement for that month." And to make matters worse, he had a separate table for storing each energy saving product verses putting them all in 1 table with a field categorizing the energy saving measure. "Just add another table if you have a new energy saving item to track." he stated. Now I could understand a TEXT (date) field if the database was a warehouse or summarization only, but these were detailed records. I was thoroughly amazed!! (especially since it took him almost a year to develop the #%@! thing.) I won't mention the cost, but I ended up redesigning it and it took me 2 weeks.

    But you're right, there might be some diehard class programmers who will give their opinion.
    Last edited by pkstormy; 06-17-07 at 02:05.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  5. #5
    Join Date
    May 2007
    Posts
    38
    i would imagine that classes with inherited properties etc are really useful, if we ever got round to using them!

    however getting used to access vb, and event driven programming to an advanced level in itself is a major exercise. most of the books concentrate on this "normal" way of programming - indeed many spend a lot of time on macros, which i never do other than autokeys macro, which you cant do with code

    once youve learnt access programming in this way you can accomplish loads - indeed everything -but you perhaps do find yourself copying stuff over from previous apps into new apps, and perhaps using a class would help get over this

    however - the classes bits tend to be add ons at the end of the instruction manual. The subject is even more intractable than normal programming, theres steep learning curve, and its often difficult to see how you would use classes practically

    so i guess a lot of us pass over the class bit!

    in the same way i've noticed that these forums very rarely feature questions on this subject

  6. #6
    Join Date
    Feb 2007
    Posts
    348
    I pretty much bought the book so I could learn all the really slick stuff built into VBA. I was surprised when the first chapter was DB theory and since then it has mostly been dealing with classes. However, I think we do get to programming forms soon.
    Based on the forward, this book had a pretty major redesign in the last edition and is trying to stay current. So the book may turn out to provide what I need programming wise, if not, I have a o'Reilly one too.
    Maybe if I was more of a coder I would appreciate it.
    In the meantime, I'm just glad I can print to a Word.doc programmatically.

  7. #7
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by starkmann
    ....since then it has mostly been dealing with classes. However, I think we do get to programming forms soon.
    You know that you have been working with classes all the time yes? Forms and reports are just a special type of class with a GUI.

    Classes are instantiated into objects. Object orientated (OO) programming involves PIE (polymorphism, inheritance, encapsulation). VBA and VB 6.0- only support encapsulation (and not even that properly). The real key to OO programming is inheritence and, following on from that, polymorphism. Since these are not available to Access programers it greatly devalues the whole point of classes IMHO. VB also does a HELL of a lot behind the scenes, stuff you cannot change, which devalues them further. I use them extensively in .NET though.

    All of my classes do something. I don't have any Customer or Order classes. I don't abstract data rows into objects and tables into collections of those objects.

    I use classes when I have very complex, verbose code that does rather a lot, for example a data access layer. My own version of the excel code I posted in the library is actually in a class in my prod work. Reason - encapsualtion. With a couple of lines of code in a form I can do a heck of a lot with excel, or insert\ update\ select my data. Why not a public function or sub then? Mainly because complex code would require a lot of input parameters. I don't much like functions with 20 input parameters. Tidier IMHO to have them as methods & properties.

    So overall my 2 cents on this would be - use them if you like, don't if you don't. I don't think there is that much gained or lost in Access regarding a developers use of classes. Remember though that they are a totally different proposition when you start getting into languages that support OO much more.

    HTH
    Testimonial:
    pootle flump
    ur codings are working excelent.

  8. #8
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by starkmann
    I think this belongs here as it is related specifically to using VBA in Access.
    as I understand it, in real VB you have to use classes.

    How many of you use classes in VBA in access. it seems like the classes mimic functions that already exist through the use of tables, at least from what little I have seen so far. I'm working through Wrox Access 2003 for beginners and the example is a Class for Car (it's a DB for a car dealer). It seems like all the class allows me to do is reference a datatype carID which doesn't seem different that a attribute carID for the table car.

    i may just need to be patient, I just thought i would see how you all use it.
    Just reread your first post. This is how classes are sometimes used, though not by me. The idea is that if your entity\ object is very complex you can incorporate a load of business rules into your class. Every time you need to deal with one of these entities, you do it via the class. The class would also probably include code to save changes back to the database too.

    As I say - I have never had need to use one. A time when I could see when I might would be if I were dealing with a complex entity that is spread across a number of related tables. Using a class I could abstract the database design away from the interface and work with one "object". Once done, the class could handle all the distribution of the data to the correct tables. Personally, I prefer to do this via stored procedures. This may be an area where you can get into heated debates between database focussed developers and front end\ middle tier developers about what belongs here. Adam Machanic has a good discussion on his blog with one such "front ender". I'll see if I can dig it out.
    Testimonial:
    pootle flump
    ur codings are working excelent.

  9. #9
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Silly me. A major advantage of classes if you use them as above is that you can have multiple objects\ collections. This slipped my mind since, as I said, I don't really use them like this
    Testimonial:
    pootle flump
    ur codings are working excelent.

  10. #10
    Join Date
    Feb 2007
    Posts
    348
    pootle (got it right this time)
    thanks for the info. I'm surprised that in VB and VB.NET they aren't used that heavily either because of the way the code is structured. Waaaay back, I spent about a semester studying computer science and we used c++ but I didn't stay with it long enough to understand classes in that form.

    I did get the feel that forms, reports and so on are classes; they have properties and methods. It seemed that those classes covered most of the uses of classes as a whole.

  11. #11
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by starkmann
    pootle (got it right this time)


    Quote Originally Posted by starkmann
    I'm surprised that in VB and VB.NET they aren't used that heavily either because of the way the code is structured.
    VB and VB.NET are leagues apart. Only the broad language syntax is similar - from the ground up they are totally differrence beasts. Up to VB6.0 OO is not really supported to any serious degree. VB7.0 & 8.0 (or VB.NET 2003 & 2005) are fully OO (or at least as near as damn it that it makes no difference to someone like me). Many VB samples on the net will include classes. They are typically of the sort i use\ create (complicated, associated code) rather than the abstracted entity style of class. Classes are used extensively in .NET. You can quite merrily program to a decent level in VB without ever having to get your head round classes - I don't really think you could in .NET.
    Quote Originally Posted by starkmann
    I did get the feel that forms, reports and so on are classes; they have properties and methods. It seemed that those classes covered most of the uses of classes as a whole.
    Quite right. You can instantiate a form just like any other class, instead of using DoCmd. I think very few people with exposure to Access only realise this. E.g:
    http://www.dbforums.com/showthread.php?t=1618905
    Testimonial:
    pootle flump
    ur codings are working excelent.

  12. #12
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    I uses classes all the time out of habit. In a VBA context there isn't a great advantage to using them, but as mentioned it is impossible to write semi-efficient code in .NET without leveraging true OO design concepts. I do use classes in access for a little encapsulation, but more in the context of convenience than true encapsulation/obfuscation. I used to write modules exclusively, but that was before I jumped on the .NET ship.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  13. #13
    Join Date
    Feb 2007
    Posts
    348
    I will definitely have to come to terms with classes in the near future then, perhaps not in terms of access though

  14. #14
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by Teddy
    I uses classes all the time out of habit. In a VBA context there isn't a great advantage to using them, but as mentioned it is impossible to write semi-efficient code in .NET without leveraging true OO design concepts. I do use classes in access for a little encapsulation, but more in the context of convenience than true encapsulation/obfuscation. I used to write modules exclusively, but that was before I jumped on the .NET ship.
    I think Teddy surmises my thoughts rather better than me

    The question got me thinking - what can you do with classes that you can't do in a typical module in Access? I think that the answer is "nothing" except if you are dealing with collections of classes, or even just 2+ instantiations of a class, then you need to go round the houses (using private arrays\ collections\ types) to work the same functionality into a module.

    Quote Originally Posted by starkmann
    I will definitely have to come to terms with classes in the near future then, perhaps not in terms of access though
    Now I am going to contradict myself I'm going to argue that Access is an excellent place to first use classes. The restrictions actually give you a "playground" where you can get to grips with the basic concept without having to think about the more advanced aspects of OO design. Once you have got comfortable with them you will keep banging your head on a ceiling thinking "I wish they could be extended to do x, y and z". Once you use a more OO language you will suddenly be able to realise all the things you wanted to do in Access. At least, that was my progression.

    HTH
    Testimonial:
    pootle flump
    ur codings are working excelent.

  15. #15
    Join Date
    Feb 2007
    Posts
    348
    Quote Originally Posted by pootle flump
    Now I am going to contradict myself I'm going to argue that Access is an excellent place to first use classes.
    makes sense. Same reason that it's a good place to start with Vb
    Do you think though that it will start and lazy, bad habits that may not have been learned if it weren't for all the extra layers of protection?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •