You are correct in the sense that a stack is used to keep track of the
state of the current 'object' though, actually it is more than an
object. One of its uses is to keep track of the current state of the
system, which may be a single variable or a single object, but can be
as many variables as are necessary to define the current system state.
Basically, a stack is a data structure concept that doesn't restrict
the kind of information in it.

It's very useful in systems programming since one needs a snapshot of
the certain system information (return memory address for example) and
the values of the arguments to a called procedure just before actually
calling it. So, one gathers up all that information, pushes it into a
stack, and calls the routine.

The use of a stack in 'day to day' programming is limited since in most
cases it is easier to use a recursively coded routine. That
effectively shifts the responsibility of managing the stack passes to
the language/compiler. This is especially true when dealing with cases
where the push/pop stack operations occur with some sense of
predictability.

That leaves the stack as a very useful data structure for
'unpredictable' instances where one needs to preserve system state.
And, in the age of event-driven programming, there are opportunities
galore. [And, when one thinks about it, calling a procedure is an
'unpredictable' event.]

One recent instance where a stack was the appropriate data structure
that comes to mind was when I was developing a PowerPoint based add-in
for a client. The add-in would monitor a slide show timing on a slide-
by-slide basis. Part of the requirement was that a slide show could
have one or more slides from which the presenter could branch to a 2nd
show. When that show ended, the presentation would resume from the
slide in the 1st show.

While the client did not expect to ever nest more than one show deep,
the correct data structure for this problem was a stack. And, that
meant I could implement n-deep nesting at no extra cost to me. So,
that's what I did. Every time a 'SlideShowBegin' event happened, my
code took all the variables that defined the system state and stuffed
them into a stack. When a 'SlideShowEnd' event occured, I saved the
information for the current slideshow in a file, and popped the stack.

--
Regards,

Tushar Mehta
www.tushar-mehta.com
Excel, PowerPoint, and VBA add-ins, tutorials
Custom MS Office productivity solutions

In article , hooksie2
@hotmail.com says...
Hi Bob,
Thanks a lot for your explaination.

I had thought maybe I could implement a stack to keep track of what
object was currently active but from what you describe using a stack
is more suited to procedures and even then of limited use since vba
will return automatically to the previous procedure once finished.

Is there any other way to identify the active object? In fact what I
really want is the object prior to the active one. Kind of like
Application.Caller but applicable to objects.

In any case, thanks for your thoughts on stacks - it sheds some light
on how a programming language may be working beneath the surface -
interesting.

Rgds,
Andrew


"Bob Kilmer" wrote in message ...
Andrew,
I haven't done a lot of stack implementation, but my general understanding
is that one use of a stack is for storing procedure variables and memory
locations while processors call other procedures. All of the current
procedure variables get stuffed onto the stack to reserve their value, along
with the memory location to resume from, and the process continues execution
at the new memory location implied by the call. The new procedure may itself
call another procedure and store its info on the same stack, and so on.
Eventually the last procedure completes, returns control to the calling
procedure which pops its variables from the stack, eventually completes,
returns control, pops variables, etc. At least that is the myth I carry
around in my head. There are other uses for stacks, as in parsing streams of
input. I am sure you can find more academic explanations.

I can envision using a VB Collection for a stack, which, as a practical
matter, would store VB objects in an order that could be controlled with
indexes. I write a lot of business and engineering software and I do not
remember implementing something I would really call a stack. Linked lists,
b-trees, arrays, other data structures, some may have been used like a stack
on a small scale. A stack is a pretty low level data type not often
encountered as such in modern business programming where the goal often is
patching together encapsulated data types (objects), data streams and whole
applications using higher level languages.

My $0.02,
Bob

"Andrew" wrote in message
om...
Last night I was reading about implementing my own stack. The example
given pushes items on and off the stack at the start and end of each
procedure (ie. in a std module). What's not so clear is how this
would work with class objects. In this case do you have to push the
object on the stack at the start of every public procedure etc. in the
class and pop it off at the end? I can't see how else you can know
which object is active - or is this not normally a situation where a
stack is employed?

Thanks in advance,
Andrew