John Colby
jwcolby at ColbyConsulting.com
Mon Oct 24 08:14:38 CDT 2005
>So while initializing the Framework Class Logging is On by default. Then
you can have it turned on or off. Right? Now, why would you want to turn it
off?
Reading your article I was under the impression that the Class Logging
feature is essential to a proper managed termination procedure?
The stacks are a troubleshooting tool, nothing more. They allow you to
discover what has loaded, in what order, and waaaay more importantly, what
has NOT unloaded.
In point of fact, the stacks can all by themselves PREVENT classes from
unloading IF for some reason the class pointer is not unloaded from the
stack when the class closes. That in fact has happened, I had a bug where a
the name I used as the index (key) for the stack collection was not the name
I was trying to use as the key for unloading the class. Oooops! It got put
in but never taken out. What happens in Access is that ANY object (and
classes are just objects) don't truly close until the last pointer to the
class is deleted from all the various variables holding that pointer.
Collections can, and my stack system does, hold pointers to classes. Since
my stack was not correctly finding and unloading the pointer to some
specific classes, they never unloaded.
So no, the stacks have nothing to do with proper unloading of the classes,
they are just a way for you to look at the names of (and count of) all the
classes loaded, then (for example) load a form that loads 20 classes, then
turn right around and close that form, and check the count of classes
loaded. If a form loads 20 classes, it MUST unload 20 classes when it
closes or it has somehow left a class open which may now be orphaned. A
troubleshooting tool.
There are obvious exceptions such as some service that the form asks the
framework to load. It was not loaded previously, but the framework opens it
and holds a pointer to that service. Now, as the form closes any classes
associated with that service will still be loaded, and that's OK. We often
leave services loaded "for the next time".
*****
>Questions:
So, Codeproject in this instance refers to your C2DbFW3G.MDA code library. I
guess this link is established when you set up the MDA in the References??
CodeProject refers to the place that code is currently executing when the
"codeproject" line of code is executed (resolved). Thus if code INSIDE the
framework executes a reference to codeproject, it points to itself (the
framework). If the FE executes the line referring to codeproject, it points
to the itself (the FE).
*****
>General question: Can you have more than one MDA linked to your FrontEnd?
If so, what is CodeProject then referring to? The first instance of MDAs in
the Reference List?
Whatever container (MDB/A/E) that the code is executing in when the
CodeProject reference is resolved.
*****
> For your demo purpose why do you have the usystblFWSysVars both in the MDA
and in the FrontEnd? It doesn't appear that the table in the FrontEnd is
used. If it was to be used, I assume it would be to demonstrate the 'over
ride' facility of the SysVar values as they exist in a particular FrontEnd.
usystblFWSysVars is used to "override" the DEFAULT behaviors of the FE.
What is SUPPOSED to happen is that the usystblFWSysVars in the framework
container (MDA) is read out and placed into the SysVars class. IMMEDIATELY
after this, the usystblFWSysVars from the FE container is supposed to be
read out and placed into the SysVars class. Since the SysVar NAME is used
as a key (index) into the SysVar class and collection, if the name is
already in the SysVar collection, an exception occurs. I trap that
exception, unload the value already in the collection, then place the "new"
value in the collection. Thus the new value "overrides" the old value.
Let's assume that I set up a DEFAULT where I do NOT USE just-in-time (JIT)
subforms. If you do not override that in the FE, then as a form loads, it
immediately loads all subforms on the form as well. Suppose that in THIS
frontend you WANT JIT subforms. Find the JITSubforms variable, set it to
true in the FE and voila, all forms in the FE will use JIT Subforms.
It turns out that we also want a form by form control over some things (like
JIT subforms), so I also have a method of overriding SysVars on a form
basis. THAT occurs in the form class however, not in the loading of the
SysVar collection as the framework loads. So you can NOT turn on JIT
subforms and still have JIT functionality for SPECIFIC forms.
*****
>If that is the case, am I correct in assuming that the usystblFWSysVars
table in the FrontEnd would be read and dealt with in the same manner as the
tables usystblAppCont usystblFWSysVars
by running similar code as
fw.SVAPPContInit "usystblAppCont"
fw.SVAPPDataInit "usystblAppData"
with the necessary functions established in the clsFramework? Or am I
missing something?
That is precisely correct. In fact you should find that I load the
usystblAppCont and usystblAppData right as the framework loads, so that by
the time control returns to the calling FE (from loading the framework) both
of those SysVar classes are loaded and ready to go.
BTW, if you are NOT particularly strong in classes ad objects, I recommend
working through the whole series, as each lecture discusses some specific
thing.
John W. Colby
www.ColbyConsulting.com
Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Borge Hansen
Sent: Monday, October 24, 2005 3:41 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] OT Colby's Framework
John,
Reply and questions inline below,
/borge
----- Original Message -----
From: "John Colby" <jwcolby at colbyconsulting.com>
Subject: Re: [AccessD] OT Colby's Framework
> One quick question, did you work
> through all the articles or are you jumping in at the end? I don't
> care,
if
> you know what you are doing and are jumping in that is cool, I'm just
> curious. If you worked through all the articles and the example code
> then
I
> am absolutely floored at your persistence. This stuff is not
> necessarily easy.
I am jumping in at the [deep] end!
I have been stepping through your code a few times, and hopefully learnt a
bit.
My knowledge and experience with class modules, objects, eventsinking etc.
is minimal.
> As for your problem, the framework is looking for a sysvar called
> "EnblPtrStack", which should be true or false. I use SysVars to turn
on/off
> functionality in my framework, and this code is telling the cIS class
> to either use the class logging mechanism or do not use it. The class
logging
> mechanism is a class which tracks the names of the classes as they are
> instantiated, so that you can get a listing in instantiation order of
> all the class instances currently loaded.
In your table "usystblFWSysVars " in the MDA code library your have the two
sysvar records: 53 EnblPtrStack 54 EnblNameStack
In the Init() code of the clsInstanceStack the corresponding two variables
blnEnblPtrStack and blnEnblNameStack are set to True by default.
So while initializing the Framework Class Logging is On by default. Then you
can have it turned on or off. Right?
Now, why would you want to turn it off?
Reading your article I was under the impression that the Class Logging
feature is essential to a proper managed termination procedure?
> I also have to say that "it is not failing here". I just opened the
> zip file, unzipped it and relinked FE to BE, and it runs perfectly, at
> least until you try and close the database, whereupon the module in
> the usysFrmFWCleanup in the framework throws a runtime error. There
> is a me. Code fragment in the form_Close. Sigh. I have fixed that
> and will upload the zip to my site.
After your reply I unzipped a 'fresh' version of your demo. Runs smoothly -
no problem (Yes, I deleted the Me. code fragment)
Last week I had problems with the MDAC and had to install latest version of
MDAC for several things to function properly.
While having the corrupt MDA on my system I had changed the
Set mfwcnn = CodeProject.Connection
to read
Set mfwcnn = CurrentProject.Connection
because my Help would'nt recognize CodeProject ,
...and I was just mocking around in the dark.
This was the reason for my demo version falling over.
I had of course forgotten about this "minor" change in the code.
Questions:
So, Codeproject in this instance refers to your C2DbFW3G.MDA code library. I
guess this link is established when you set up the MDA in the References??
General question: Can you have more than one MDA linked to your FrontEnd? If
so, what is CodeProject then referring to? The first instance of MDAs in the
Reference List?
For your demo purpose why do you have the usystblFWSysVars both in the MDA
and in the FrontEnd? It doesn't appear that the table in the FrontEnd is
used. If it was to be used, I assume it would be to demonstrate the 'over
ride' facility of the SysVar values as they exist in a particular FrontEnd.
If that is the case, am I correct in assuming that the usystblFWSysVars
table in the FrontEnd woud be read and dealt with in the same manner as the
tables usystblAppCont usystblFWSysVars
by running similar code as
fw.SVAPPContInit "usystblAppCont"
fw.SVAPPDataInit "usystblAppData"
with the necessary functions established in the clsFramework?
Or am I missing something?
/borge
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com