[AccessD] 64-but ONLY front end ?

[John Colby]

 >> Sorry, but inheritance is a major concept in the use of them, not a 
minor one. Not having it certainly diminishes what you can do with them.

And what I have found is that entire projects get bogged down with "how 
should we inherit this thing".  And "oh shit, we inherited the wrong 
level, let's back up..." and so forth.  Inheritance is itself a two 
edged sword, use it wrong and it can royally screw you.

Yes, inheritance is useful, that is why it exists, but the lack thereof 
doesn't make the class not worth learning and using. Classes are WAY 
more powerful than modules precisely BECAUSE they can sink and source 
events, and can hold instances of data.  And yet the very first thing we 
tell the nube to do is learn modules and libraries.  So we tell them to 
use the much less powerful module and then tell them to not bother with 
learning much more powerful classes?

 >The one thing for sure that classes in VBA buys you is the ability to 
deal with multiple instances of something.

Yep.  What they /really /allow is for us to "model" objects.  To store 
the code and data for an instance of something.

Before I learned classes I used to use collections to hold multiple 
instances of things.  And then collections of collections.  Damned 
ugly.  Particularly ugly since the code and data for those objects had 
to be elsewhere.  Nowhere is that even remotely a model of what I was 
trying to deal with.

Try to do something like the combo control wrapper I mentioned without a 
class?  Where do you store the event sink?  I do this exact thing in my 
framework, I use a class, and I do so because I was sick of my form 
classes looking like a Walmart store, dealing with 47,258 different 
event sinks for objects that I was trying to model.  "Combo events on 
Isle two", "Text events on Isle four".  I spent more time paging down 
through my gargantuan form modules than I did programming.

 >In regards to your list, #2 and #3 can be achieved easily just with a 
find and replace

LOL.  Can you say ICK?  Major project maintenance by S&R?

"Easily" is the key term here.  Find and replace is NEVER easy in a 
large project.  Rick Fischer's tool is a key for us all.  But having to 
watch CAREFULLY as each find is displayed is NOT easy. To say this is an 
"Easy" replacement for a powerful tool is silly.

 >Look at what you do when you need to base all your text controls on 
your own textbox class. You can't simply go back and modify the base 
class, but must hookup each control individually to your class.

No but you can go back and modify your object wrapper.  Or you can use 
Find And Replace to search for code and change it when (if) you find it.

And isn't that exactly what Access is doing for you by "hooking up" all 
the events using the properties wizard? Of course you have to do that, 
whether you use class wrappers or not. But if that is such a chore, why 
are (or were) you using Access at all?

 >Hum...well I'd ask you the flip question; if classes in VBA are such a 
great thing, then why don't you see more developers using them? I mean 
after all, their not that hard to figure out and there are a lot of 
smart developers out there.

Classes are in fact hard to figure out if you don't come in from some 
other class oriented language.  It took me three tries before I got it.  
And many, perhaps even most Access programmers started as power users, 
not programmers.  VBA was marketed as the language that anyone could 
figure out.  But NOWHERE in the literature were classes mentioned.  To 
this day that is still true.  Given the absolute absence of mention 
anywhere in MS literature, I have to believe that it is intentional on 
MS part.  You'd have to ask MS why.

So how are you supposed to learn them if the books never even mention 
them.  Unless you have a Shamil or a John Colby to be there to teach it?

 > wouldn't you expect to see article after article on how to use them, 
build apps with them, etc. and see applications written primarily with 
them? But do you find any of that? No.

See my lectures and my apps.

Why aren't they mentioned by Microsoft? I think it is simply because 
Microsoft wanted Access to be a simple database tool for quick and dirty 
desktop apps.  Classes are many levels up from that.  Access has their 
own agenda, which includes support issues.

But in the end they exposed the class object for us to use.  To not do 
so is to waste the most powerful of all the objects, the object that is 
itself the basis behind every single other object in Access.  If 
Microsoft used them, even without the ability to allow inheritance, I 
would be silly not to do the same.


On 1/7/2017 10:48 AM, Jim Dettman wrote:
> John,
>
> <<To say that a tool isn't useful because it doesn't have a specific
> function is simply not true. >>
>
>   I never said they were not useful.  In fact if you read, I said:
>
> "There are places where using classes in VBA make sense, but I don't see
> where you gain any advantage for something like this"
>
> << In fact inheritance is only one smallish part of the usefulness of the
> class object.>>
>
>   Sorry, but inheritance is a major concept in the use of them, not a minor
> one.  Not having it certainly diminishes what you can do with them.
>
> <<The CLASS
> ITSELF behind the form, is JUST A CLASS, the same EXACT thing as the
> class you too could use if you removed your prejudices.>>
>
>   I totally understand that and use classes all the time, just not so much
> with VBA.   Obviously all the Access objects are classes, but I don't often
> build my own classes with VBA.
>
>   The one thing for sure that classes in VBA buys you is the ability to deal
> with multiple instances of something.  But with VBA being object based
> rather than object orientated, you loose a lot of the benefits and it costs
> you in the extra work you need to go through, plus the additional overhead
> (if your truly encapsulating, then you spend a lot of time checking the
> state of things).  Look at what you do when you need to base all your text
> controls on your own textbox class.   You can't simply go back and modify
> the base class, but must hookup each control  individually to your class.
>
>   In regards to your list, #2 and #3 can be achieved easily just with a find
> and replace and directly calling a procedure without all the additional
> overhead.  #4 you really don't need all that often, but it does come in
> handy when you need it.
>
>   A good example of that would be a customer combo.   You might have many
> instances on the open forms, so it's nice to be able to raise a requery
> event after adding a customer and have them all requery on their own.
> While you can achieve that without classes, it's certainly slicker with
> them.
>
> <<So riddle me this batman,...>>
>
> <<As I have just pointed out, there is not a single Access programmer who
> doesn't use classes, only those who go the next step to figuring that
> little object called a class.>>
>
>   Hum...well I'd ask you the flip question; if classes in VBA are such a
> great thing, then why don't you see more developers using them?   I mean
> after all, their not that hard to figure out and there are a lot of smart
> developers out there.
>
>   If they were really that useful in VBA, after all these years, wouldn't you
> expect to see article after article on how to use them, build apps with
> them, etc. and see applications written primarily with them?   But do you
> find any of that?  No.
>
> Jim.
>
>
-- 
John W. Colby