[AccessD] 64-but ONLY front end ?

Sat Jan 7 07:25:32 CST 2017

 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