John Colby
jcolby at colbyconsulting.com
Sun Oct 5 21:16:35 CDT 2003
David, Yes, the short load time as the tab is clicked on is simply the result of not suffering that load time when the form first opens. Either way the user has to wait, up front or if they use a tab. As for the Sysvars... As the list old-timers know, I use a framework to speed my development time. I have a class for each control that Access offers, which means I have a class for the tab control, the subform control, the combo, list text box etc. And of course all of these control / form classes sink the events that the control generates so that the class handles all generic event processing - Withevents. In addition I have other classes such as a SysVar class, which BTW you can find the basis of in the articles I wrote for Database Advisors. My tab control is what implements the JIT functionality for me. IOW, the tab class sinks the click event. It determines if the user has just moved to another tab, and if so it asks the parent form class if it is supposed to use JIT - in fact it asks this at class load time. The parent form has loaded a Sysvar that says whether the application in general uses JIT, if so, does it unload the subform as the user clicks off the tab. However the form can also look for and find SysVars SPECIFIC TO ITSELF that over-rides the generic behavior. IOW: gJITSFrms true Global Just In Time SubFrms. True = turn on JIT subforms, False = turn them off. gJITSFrmUnload False Global - True means unload JIT subforms when you tab away from the tab. False means once loaded, leave them loaded However each form class (as it loads) looks for a sysvar with its name embedded in the sysvar that over-rides the application wide preferences. fJITSFrmUnloadtfrmEmployee True Local - True means FOR THIS FORM... unload JIT subforms when you tab away from the tab. False means once loaded, leave them loaded The g prefix in the sysvar name means that is the global behavior. A f prefix means that this behavior over-rides the global behavior only for the form whose name is embedded in the SysVar. This allows me to have a set of SysVars (a SysVar table) for my framework that resides out in my framework library - called usystblFWSysVars. That is loaded first, and sets up the framework to work a "default" way. IF I wish to do so, I then add usystblFEFWSysVars - notice it is the same name with FE embedded in there. This table physically resides in the FE itself and I can place any or all of the exact same name SysVars in this table but with a value different from the one residing in the Framework library. The load order is Lib table then FE table, with the value in the FE table over-riding (overwriting the value) from the framework library table if it exists in the FE. Same SysVar name, different value, loaded last, overrides the original. Thus each FE can decide that the default functionality of the framework should differ. Of course the values specific to forms then override the values generic to the FE or the framework. The form specific values are searched for and loaded BY THE FORM CLASS as the form loads, whereas the global SysVars, both Framework and FE are loaded as the FE opens. Because of the fact that the last value loaded into the class overwrites any previous value loaded, and because the control / form class knows how to use any generic sysvar but also look for the control or form name in the SysVar name and use that to overwrite the generic SysVar, I can overload ANY Sysvar, ANY behavior, on a case by case, form by form, control by control basis. Thus the app for company A can be completely generic, whereas the App for company B can be customized to a T, all by doing nothing more than throwing in a bunch of Sysvars into the FE sysvar table with object names embedded in (at the end of) the SysVar name. I have even toyed with the idea of setting up a USER LEVEL over-ride to allow each user to decide whether they want the behavior, but I decided that would be a dangerous thing to do. OK, I've no doubt bored you to tears, but if you are thinking of using SysVars, think about how to allow turning on / off functionality at the library level. Once you can do that, allow over-riding that in each app, then once that works, allow over-riding that for any given control / form. Works great, and makes application customization a snap. John W. Colby www.colbyconsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of David Fenton Sent: Sunday, October 05, 2003 9:12 PM To: accessd at databaseadvisors.com Subject: [AccessD] RE: Just in Time (off shoot of Can't open any more databases) -Thank you Hello Charlotte and John, You have both solved my hassles with the Can't load anymore databases. I implemented JIT properly this time and it seems to have fixed the problem. When the user clicks on a tab, the unbound subform takes about a second or so to refresh itself after my code assigns the SourceObject, but the users will have to live with that. John, I like your idea of unloading (when the user clicks on a different tab) the SourceObject from the subforms using a global sysvar and may also implement that in my application. I am grateful for you help. Cheers David Ô¿Ô¬ Brisbane Australia