[AccessD] Imitating a STACK

No, there are no repercussions at all.  It is just records being written to
a table and removed from a table.  Easy peasy.  It does not write anything
to memory etc.  It is purely a record of the path through the program.


You KNOW what the tool is, I promise.  I just cannot bring it to mind.  It
installs as an add-in and has a host o things installed across the menu
items bar.  I KNOW Susan and Charlotte use it because they have mentioned
it.

Currently listening to: http://www.tropicalglen.com/ thanks to Alan Lawhon

Max



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence
Sent: 24 June 2009 21:31
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Imitating a STACK

Hi Max:

What you have represented there is a solution to situation that could not be
handled any other way... Something like the use of a GOTO statement for
handling errors, in an Access function. 

As long as each Push is matched with a Pop no problem and the method is kept
clean and simple.

On the other hand if anything goes wrong and for some reason processes, like
a programmer makes a coding error (not something that we would ever have to
worry about), there can be some serious repercussions.

If you ever remember or run across that tool location or link, I would be
very interested.
 
Jim 


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Wanadoo
Sent: Wednesday, June 24, 2009 12:37 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Imitating a STACK

Jim,
This is what I was trying to get at when I responded to Arthur's question re
CallByForm, which wasn't what I was after.

What I have to do to simulate the STACK is to provide a means to record that
every time I enter a function/sub it is recorded and every time I leave the
function/sub it is recorded.

You can only reliably PUSH the STACK and POP the STACK if you have ONE ENTRY
point and ONE EXIT point.

When an error occurs and you are using a error handling routine in a
module/class then it is easy to look at the STACK to identify how you
progressed through the program to the point of the errors. All
functions/subs you encountered on the way are available to you.

I use a Global Boolean variable called gvRecordProgress.  On each
Function/Sub I have a line which says:

Private function myfunctionname
On error goto pfMyGlobalErrorHandler
If gbRecordProgress = true the call pfPushStack("Push","myfunctionname")

Code
Code

Onexit:
If gbRecordProgress = true the call pfRecordStack("Pop","myfunctionname")
Code
Exit function

End function

Now, before you all go screaming at me, the above is taken from memory and I
do not have access to Access (!) but you will get the general concept.  The
names have been plucked out of the air.  This is just so that I can
illustrate what I mean.

You can switch it on/off by just changing the value of gbRecordProgress.

This is also a useful way to see which functions/sub are used the most - ie,
where tightening up of code would result in a big improvement overall.

NOW: To get the two lines in, if you have that little toolset (mxtools or
something like that) you can tell it to do the above for you and whilst it
is doing it, it can actually insert the function/sub name into the line, so
it only takes seconds  Apologies for not remembering the name of the tool,
but you all know it because you have mentioned it here many times.



Max
Ps. Changed subject.



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence
Sent: 24 June 2009 20:11
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Learning .Net -- PHP Instead?

Hi guys:

In the old days, some 30 years back I did a lot of assembler coding and
discovered a very neat technique for returning from a chunk of code back to
anywhere in application. You would just push the address of where you wanted
to return to, on the stack. That was great, as the stack pointer did not
have to be set to return to the caller module. I would first set the return
address to the error handler to trap any errors, in the called module and
then if code completed successfully, the stack pointer was set then set to
any position in the program you wanted to jump to, and then a return byte
was processed.

The assembler, I was using was designed to auto adjust all the changes in
module position. Of course there was no internal documentation (no memory)
other than a ref number to a code book.

This little trick sure saved a lot of code and made the modules very
flexible... 

The down side was if you ever lost the code printout and needed to make some
changes, with all its documentation, you were screwed. I ended up being
raked over the coals after someone lost my documentation manual. It took 3
people, 2 weeks to rebuild the code.

At that point, I learned my lesson about the proper methods of using RETURNS
and explicit GOTOs.

Jim      


-- 
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