[AccessD] 64-but ONLY front end ?
Jim Dettman
jimdettman at verizon.net
Sat Jan 7 09:48:41 CST 2017
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.
-----Original Message-----
From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
John Colby
Sent: Saturday, January 07, 2017 09:43 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] 64-but ONLY front end ?
Jim,
To say that a tool isn't useful because it doesn't have a specific
function is simply not true. In fact inheritance is only one smallish
part of the usefulness of the class object.
Do you say that a combo control is not useful because you can't inherit
it? Personally I find it very useful. A combo class, like everything,
and I do mean EVERYTHING in Access is a class. Every control is a
class. All of the dao objects are classes. Ever program a recordset?
You are instantiating a class.
And no, you can't inherit these things but they are still mighty useful,
and every single access programmer uses them.
Classes do the following:
1) Store all the code for the object being modeled in a common place
specifically for that object.
2) Allow creating instance specific data storage for an object being
modeled (CRITICAL STUFF HERE).
3) Sink events for an object that generates events (CRITICAL STUFF HERE).
4) Raise events of its own to be sinked elsewhere in code .
5) Allow inheritance.
Notice of that list, only the last is missing.
So riddle me this batman, do you use the form class? Of course you do.
Well guess what, the form class is EXACTLY the same object as the class
that you can build using the generic class object. The Access program
has a bunch of "builders" which allow you the developer to "double
click" on a control object and insert an event handler into a form's
class but that is just a builder helping you do something. 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.
So why do you say that it is useless because you cannot inherit it? Yep,
you cannot inherit the form class, but I bet you dollars to donuts you
use the form class anyway.
You use the class object, literally all day every day, and then tell me
it isn't useful. Baffling.
The only difference between me and those who don't "use classes" is I
took the time to understand them and actually start using them daily in
my code.
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.
On 1/7/2017 8:25 AM, Jim Dettman wrote:
> Code though is not where you chew up most of your memory and certainly
you
> can structure your procedures to be used by more than one object, so you
> don't need classes to avoid that.
>
> <<You will find that most Access programmers haven't used classes, though
> those that have tend to swear by them.>>
>
> As we've talked about in the past, I don't believe it's that people
don't
> understand them, but rather the fact that VBA doesn't support full
> inheritance, so the power of classes is really robbed. That's why you
> don't see classes used a lot more with Access.
>
> 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 it seems
> like it would be a disadvantage. Not only do you have to go through the
> effort of adding code to instantiate everything, but you now have a bunch
of
> additional objects in memory.
>
> Jim.
>
> -----Original Message-----
> From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
> John Colby
> Sent: Saturday, January 07, 2017 01:04 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] 64-but ONLY front end ?
>
> Yes, my way means instantiating a bunch of classes. Understand though
> that the code itself in any given class is only loaded once and is then
> shared between all of the classes. Only the variable storage is created
> more than once.
>
> Whereas if you store event code for each tab in the form class which
> contains the tab, that code is created over and over (and over and
> over), once for each event for each tab.
>
> You will find that most Access programmers haven't used classes, though
> those that have tend to swear by them. Those that don't swear at them.
> ;) But once you wrap your brain around the class concept you will never
> go back.
>
> On 1/6/2017 7:57 PM, Ryan Wehler wrote:
>> I sure would love to pick your brain on that. I've not done much with
user
> created classes.
>> Wouldn't your way mean instantiating an object per tab and an object per
> subform?
>> Seems like a lot of stuff to keep in memory when I'm trying to avoid
> memory usage. But I'd love to hear more.
>> I'm a visual learner though ... examples get me going a lot faster than
> just a wall of words but I'll do my best to follow along if you can find
the
> time to discuss this more.
>> Sent from my iPhone
>>
>>> On Jan 6, 2017, at 5:55 PM, John Colby <jwcolby at gmail.com> wrote:
>>>
>>> Ryan, think about using a table to store the subform control name /
> subform name and other link info. This allows it to be "table driven",
one
> of my favorite concepts. You have a place to go to see what subforms are
> linked to what subform controls. Then you can use a collection to load
the
> table into class instances one time as the app opens, one instance for
each
> record, thus "caching" that info for instantaneous usage. IIRC you can
> store objects in the collection using a name so that you can index
directly
> into the correct record when needed.
>>> If you use classes this stuff is much easier. The classes contain the
> code to do the linking / unlinking, loading the data from the table etc.
>>> You would need a tab class (to sink the events generated by clicks or
> focus), a subform control class to hold the subform name and link data,
and
> a collection class to load all that table stuff into.
>>> As a main form with tabs loads, it will load a tab class for each tab.
> The tab class would load a subform control class for the embedded subform
> control. The subform control class would go get it's link info. Then as
> the user clicks or otherwise causes a tab to get the focus the event would
> call into the subform control class to tell it to load the subform and
link
> it up. As it loses the focus, it calls back into the class to tell it to
> unload.
>>> I did all this stuff in my framework, but never tested it in later
> versions of access.
>>> jwc
>>>
>>> I'd be interested to know what is using up all the memory though. I did
> run into the limitation of open record sets which is why I did this stuff.
> Never ran into the thing you are discussing. Of course it might be
> something triggered by changes in the 2013 version. I never used anything
> past 2007.
>>>> On 1/6/2017 6:26 PM, Ryan Wehler wrote:
>>>> John,
>>>>
>>>> That's more or less what I ended up doing today. :) it probably
needs
> some fine tuning though.
>>>> Sent from my iPad
>>>>
>>>>> On Jan 6, 2017, at 5:17 PM, John Colby <jwcolby at gmail.com> wrote:
>>>>>
>>>>> Ryan,
>>>>>
>>>>> I did what I referred to as "JIT subforms", i.e. linking the subforms
> when the tab was clicked on. I used a class (of course) to manage it.
The
> event on the tab triggered a method in the loaded class to link the
> suvbform. When the user moves off the tab, the subform is unlinked. Of
> course you end up with situations where you need specific forms to remain
> linked once the tab is clicked, typically subforms that are used often and
> require a long time to load once linked.
>>>>> IIRC I used SysVars to store the names of the subforms that would
> remain loaded.
>>>>> It took a bit of dev work but once working it worked quite well.
>>>>>
>>>>> jwcolby
>>>>>
>>>>>> On 1/6/2017 9:28 AM, Ryan W wrote:
>>>>>> More statistics:
>>>>>>
>>>>>> ?returnvm
>>>>>>
>>>>>>
>>>>>> (Reporting module loaded)
>>>>>> 1.391 GB of VM used.
>>>>>>
>>>>>> (Prepatory form loaded)
>>>>>> 1.194 GB of VM used.
>>>>>>
>>>>>> (Analytics form loaded)
>>>>>> 1.135 GB of VM used.
>>>>>>
>>>>>> (Login Form loaded)
>>>>>> 1.06 GB of VM used.
>>>>>>
>>>>>> (Switchboard Loaded)
>>>>>> 0.803 GB of VM used.
>>>>>>
>>>>>> (Nothing open but my Access FE (no forms loaded))
>>>>>> 0.645 GB of VM used.
>>>>>>
>>>>>>
>>>>>>
>>>>>> With that once I get to the reporting module if I hit "print preview"
> on
>>>>>> all of my selected reports (7) to print and give to the client I get
> an out
>>>>>> of resources error. Those are the most used forms in the entire FE.
> It
>>>>>> wouldn't be uncommon for some of our data reviewers to have all of
> those
>>>>>> open bouncing between them (they used to do it before via hotkeys
> (Ctrl-R
>>>>>> for Analytical, Ctrl-M for Main, Ctrl-B for Prep, Ctrl-W for Login
> etc)..
>>>>>> so even though you PREVIOUSLY with Access 2003 you couldn't see a
tab,
> the
>>>>>> same forms were loaded then that are loaded now. The key difference
is
>>>>>> Access 2013. It must simply use more memory.
>>>>> --
>>>>> John W. Colby
>>>>>
>>>>> --
>>>>> AccessD mailing list
>>>>> AccessD at databaseadvisors.com
>>>>> http://databaseadvisors.com/mailman/listinfo/accessd
>>>>> Website: http://www.databaseadvisors.com
>>> --
>>> John W. Colby
>>>
>>> --
>>> AccessD mailing list
>>> AccessD at databaseadvisors.com
>>> http://databaseadvisors.com/mailman/listinfo/accessd
>>> Website: http://www.databaseadvisors.com
--
John W. Colby
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
More information about the AccessD
mailing list