[AccessD] 64-but ONLY front end ?

Fri Jan 6 19:59:56 CST 2017

Ryan,

John Colby is THE MAN when it comes to classes.

He did a series of classes "lectures" on the list back in February or
March of 2009.

You can find them in the archives at
http://databaseadvisors.com/pipermail/accessd/

Here is the list of emails and direct links to them in the archive for
you to read:

1) [AccessD] Classes and Events
http://databaseadvisors.com/pipermail/accessd/2009-February/082643.html

2) [AccessD] CREATE CLASSES AND EVENTS DEMO DATABASE
http://databaseadvisors.com/pipermail/accessd/2009-February/082677.html

3) [AccessD] LOAD THE FORM CLASS IN THE FORM
http://databaseadvisors.com/pipermail/accessd/2009-February/082681.html

4) [AccessD] Get event sinks working
http://databaseadvisors.com/pipermail/accessd/2009-February/082688.html

5) [AccessD] Building a Control Scanner
http://databaseadvisors.com/pipermail/accessd/2009-February/082693.html

6) [AccessD] Building a control class
http://databaseadvisors.com/pipermail/accessd/2009-February/082694.html

7) [AccessD] MODIFY THE FORM CLASS TO LOAD THE NEW COMBO CLASS.
http://databaseadvisors.com/pipermail/accessd/2009-February/082695.html

8) [AccessD] Classes and Events - EVENTS NOT REQUIRED
http://databaseadvisors.com/pipermail/accessd/2009-February/082707.html

9) [AccessD] BUILDING A TEXT CONTROL CLASS
http://databaseadvisors.com/pipermail/accessd/2009-February/082771.html

10) [AccessD] The classes as they are at this instant - clsTimer
http://databaseadvisors.com/pipermail/accessd/2009-February/082774.html

11) [AccessD] The classes as they are at this instant - clsCtlCbo
http://databaseadvisors.com/pipermail/accessd/2009-February/082775.html

12) [AccessD] The classes as they are at this instant - clsCtlTxt
http://databaseadvisors.com/pipermail/accessd/2009-February/082776.html

13) [AccessD] The classes as they are at this instant - clsFrm
http://databaseadvisors.com/pipermail/accessd/2009-February/082777.html

14) [AccessD] The form
http://databaseadvisors.com/pipermail/accessd/2009-February/082781.html

15) [AccessD] IMPORT THE FORM
http://databaseadvisors.com/pipermail/accessd/2009-February/082787.html

16) [AccessD] SINKING EVENTS IN MULTIPLE PLACES
http://databaseadvisors.com/pipermail/accessd/2009-February/082844.html

17) [AccessD] EMERGENCY HALT: was Re: The form for demo event sink in two places
http://databaseadvisors.com/pipermail/accessd/2009-February/082848.html

18) [AccessD] Demo sinking events in two places
http://databaseadvisors.com/pipermail/accessd/2009-February/082849.html

19) [AccessD] ClsMsg
http://databaseadvisors.com/pipermail/accessd/2009-February/082881.html

20) [AccessD] CLSMSG DEMO
http://databaseadvisors.com/pipermail/accessd/2009-February/082889.html

21) [AccessD] USING CLSMSGDEMO
http://databaseadvisors.com/pipermail/accessd/2009-February/082890.html

Don't just read those emails, but the entire threads. They may contain
good info too.

Bryan

On 6 January 2017 at 17:57, Ryan Wehler <wrwehler at gmail.com> 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
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com

-- 
Bryan Carbonnell - carbonnb at gmail.com
Life's journey is not to arrive at the grave safely in a
well-preserved body, but rather to skid in sideways, totally worn out,
shouting "What a great ride!"