View Single Post
  #5   Report Post  
Posted to comp.lang.visual.basic,microsoft.public.excel.programming
Andrew[_16_] Andrew[_16_] is offline
external usenet poster
 
Posts: 66
Default When to use a stack?

To clarify...
First up - I am working with vba running in xl.

I have been working my way through Ken Getz & Mike Gilbert's book, the
"VBA Dev's Handbk", over a period of time. Here I came across an
example of how to implement your own stack using two class objects.
So, from a learning point of view I am curious to know more about when
and for what you would use a stack. I can see (from the example) how
this could be used within standard modules although am not so sure why
you want to do that really. Bob's reply seems to indicate that as
well. In parallel, however, I am writing my own program - hopefully
applying some of what I learn along the way. My code is object based
so as part of my understanding of stacks I am curious as to whether a
custom stack can be used with class objects. As far as I can tell
this would be overly arduous.

Then comes my project specific question which I thought could be
solved by maintaining a stack - but you are right there may be a
completely different and more optimal solution out there.

Say I have 2 objects: cStream and cPipe. I create two instances of
cStream, Inlet and Outlet and one instance of cPipe, MyPipe. Pointers
to Inlet and Outlet are held by MyPipe. When the inlet stream is
passed a pressure value an event is raised which is picked up by
MyPipe. If MyPipe is able to calculate the pressure drop across it,
dP, then it should pass the downstream pressure to the outlet stream
(ie. Outlet.Pressure = Inlet.Pressure + Me.dP). Conversely, if outlet
pressure is set then inlet pressure should be calculated.

The trick is though, I need to also record where the outlet pressure
(or inlet pressure) came from because if Outlet.Pressure is calculated
but then someone tries to enter a value for it then I need to raise an
error. But I don't want to raise an error if inlet pressure is
changed and a new outlet pressure is calculated. This is where I
thought a stack could be of use.

Sincere apologies for kind of confusing two questions in one.

Thanks for your help,
Andrew


"Tom Ogilvy" wrote in message ...
selection will identify what is selected.

Perhaps if you said what you are really trying to do, someone could make a
suggestion. (as opposed to asking questions specific to how to implement
aspects of your creative solution which may not be the best way to attack
the problem). Also, since you are posting in comp.lang.visual.basic
perhaps if you mentioned where the code will be running - in excel or from a
vb app manipulating Excel with with automation or something else altogether.
--
Regards,
Tom Ogilvy

"Andrew" wrote in message
om...
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