When to use a stack?

[Andrew]

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

[Bob Kilmer]

Re: When to use a stack?

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" <hooksie2@hotma il.com> wrote in message
news:9dfb6bbd.0 409021606.6a1fa 1de@posting.goo gle.com...[color=blue]
> 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[/color]

[Andrew]

Re: When to use a stack?

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.Cal ler 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" <rprgrmr@yahoo. com> wrote in message news:<ep8wbqWkE HA.2500@TK2MSFT NGP09.phx.gbl>. ..[color=blue]
> 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" <hooksie2@hotma il.com> wrote in message
> news:9dfb6bbd.0 409021606.6a1fa 1de@posting.goo gle.com...[color=green]
> > 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[/color][/color]

[Tom Ogilvy]

Re: When to use a stack?

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.visua l.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" <hooksie2@hotma il.com> wrote in message
news:9dfb6bbd.0 409030532.678ce 76e@posting.goo gle.com...[color=blue]
> 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.Cal ler 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" <rprgrmr@yahoo. com> wrote in message[/color]
news:<ep8wbqWkE HA.2500@TK2MSFT NGP09.phx.gbl>. ..[color=blue][color=green]
> > Andrew,
> > I haven't done a lot of stack implementation, but my general[/color][/color]
understanding[color=blue][color=green]
> > 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,[/color][/color]
along[color=blue][color=green]
> > with the memory location to resume from, and the process continues[/color][/color]
execution[color=blue][color=green]
> > at the new memory location implied by the call. The new procedure may[/color][/color]
itself[color=blue][color=green]
> > 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[/color][/color]
streams of[color=blue][color=green]
> > 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[/color][/color]
lists,[color=blue][color=green]
> > b-trees, arrays, other data structures, some may have been used like a[/color][/color]
stack[color=blue][color=green]
> > 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[/color][/color]
is[color=blue][color=green]
> > patching together encapsulated data types (objects), data streams and[/color][/color]
whole[color=blue][color=green]
> > applications using higher level languages.
> >
> > My $0.02,
> > Bob
> >
> > "Andrew" <hooksie2@hotma il.com> wrote in message
> > news:9dfb6bbd.0 409021606.6a1fa 1de@posting.goo gle.com...[color=darkred]
> > > 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[/color][/color][/color]

[Dana DeLouis]

Re: When to use a stack?

If you would like to see an "Out of stack space" message in vba, here is one
way: In Excel XP, my limit is about 6,285. I think this limit was
increased from about 2,000+ in previous versions.

Option Explicit

Public n As Long

Sub Repeat()
On Error Resume Next
n = n + 1
Debug.Print n
Call Repeat
If Err.Number <> 0 Then
Debug.Print Err.Description
Stop
End If
End Sub

Dana DeLouis


"Andrew" <hooksie2@hotma il.com> wrote in message
news:9dfb6bbd.0 409030532.678ce 76e@posting.goo gle.com...[color=blue]
> 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.Cal ler 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" <rprgrmr@yahoo. com> wrote in message[/color]
news:<ep8wbqWkE HA.2500@TK2MSFT NGP09.phx.gbl>. ..[color=blue][color=green]
> > Andrew,
> > I haven't done a lot of stack implementation, but my general[/color][/color]
understanding[color=blue][color=green]
> > 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,[/color][/color]
along[color=blue][color=green]
> > with the memory location to resume from, and the process continues[/color][/color]
execution[color=blue][color=green]
> > at the new memory location implied by the call. The new procedure may[/color][/color]
itself[color=blue][color=green]
> > 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[/color][/color]
streams of[color=blue][color=green]
> > 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[/color][/color]
lists,[color=blue][color=green]
> > b-trees, arrays, other data structures, some may have been used like a[/color][/color]
stack[color=blue][color=green]
> > 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[/color][/color]
is[color=blue][color=green]
> > patching together encapsulated data types (objects), data streams and[/color][/color]
whole[color=blue][color=green]
> > applications using higher level languages.
> >
> > My $0.02,
> > Bob
> >
> > "Andrew" <hooksie2@hotma il.com> wrote in message
> > news:9dfb6bbd.0 409021606.6a1fa 1de@posting.goo gle.com...[color=darkred]
> > > 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[/color][/color][/color]

[Andrew]

Re: 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" <twogilvy@msn.c om> wrote in message news:<#REx4kckE HA.524@TK2MSFTN GP15.phx.gbl>.. .[color=blue]
> 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.visua l.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" <hooksie2@hotma il.com> wrote in message
> news:9dfb6bbd.0 409030532.678ce 76e@posting.goo gle.com...[color=green]
> > 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.Cal ler 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" <rprgrmr@yahoo. com> wrote in message[/color]
> news:<ep8wbqWkE HA.2500@TK2MSFT NGP09.phx.gbl>. ..[color=green][color=darkred]
> > > Andrew,
> > > I haven't done a lot of stack implementation, but my general[/color][/color]
> understanding[color=green][color=darkred]
> > > 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,[/color][/color]
> along[color=green][color=darkred]
> > > with the memory location to resume from, and the process continues[/color][/color]
> execution[color=green][color=darkred]
> > > at the new memory location implied by the call. The new procedure may[/color][/color]
> itself[color=green][color=darkred]
> > > 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[/color][/color]
> streams of[color=green][color=darkred]
> > > 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[/color][/color]
> lists,[color=green][color=darkred]
> > > b-trees, arrays, other data structures, some may have been used like a[/color][/color]
> stack[color=green][color=darkred]
> > > 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[/color][/color]
> is[color=green][color=darkred]
> > > patching together encapsulated data types (objects), data streams and[/color][/color]
> whole[color=green][color=darkred]
> > > applications using higher level languages.
> > >
> > > My $0.02,
> > > Bob
> > >
> > > "Andrew" <hooksie2@hotma il.com> wrote in message
> > > news:9dfb6bbd.0 409021606.6a1fa 1de@posting.goo gle.com...
> > > > 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[/color][/color][/color]

[Tom Ogilvy]

Re: When to use a stack?

On pg 440 they tell you why you might want to use a stack. In your example,
I don't see any match to using a stack. Your explanation for an application
appears asynchronous - having no set pattern or sequence. A stack is used
when a sequential path is followed and then reversed. I would see a stack
storage paradigm being applicable to a search, such as a depth first search
where your confronted with multiple choices (as to path) along the way
[basically a tree structrue]. When you reach the bottom of one path, you
would walk backup to the next juncture. This would involve pushing and
popping information on the stack. You would always want the information for
the last node visited, which the stack provides. The stack is basically a
LIFO queue. Now if you were traversing some type of pipe network, then
perhaps a stack would be appropriate.

That said, you do say you want to know how the value was set. I think you
would have to have all your code that could set the value, update you stack.
Then your procedure could check the stack to see how the the variable was
set. However, if you don't need to move back "up" the stack, but only know
about the most recent setting, then a global variable, class attribute, or
similar should add all the functionality you need

Unfortunately, when you mention stack, most people immediately focus on the
calling stack which uses the stack storage paradigm. Thus Dana has shown
you how to overflow that stack.



--
Regards,
Tom Ogilvy

"Andrew" <hooksie2@hotma il.com> wrote in message
news:9dfb6bbd.0 409040153.6d597 b75@posting.goo gle.com...[color=blue]
> 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" <twogilvy@msn.c om> wrote in message[/color]
news:<#REx4kckE HA.524@TK2MSFTN GP15.phx.gbl>.. .[color=blue][color=green]
> > selection will identify what is selected.
> >
> > Perhaps if you said what you are really trying to do, someone could make[/color][/color]
a[color=blue][color=green]
> > suggestion. (as opposed to asking questions specific to how to[/color][/color]
implement[color=blue][color=green]
> > aspects of your creative solution which may not be the best way to[/color][/color]
attack[color=blue][color=green]
> > the problem). Also, since you are posting in comp.lang.visua l.basic
> > perhaps if you mentioned where the code will be running - in excel or[/color][/color]
from a[color=blue][color=green]
> > vb app manipulating Excel with with automation or something else[/color][/color]
altogether.[color=blue][color=green]
> > --
> > Regards,
> > Tom Ogilvy
> >
> > "Andrew" <hooksie2@hotma il.com> wrote in message
> > news:9dfb6bbd.0 409030532.678ce 76e@posting.goo gle.com...[color=darkred]
> > > 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.Cal ler 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" <rprgrmr@yahoo. com> wrote in message[/color]
> > news:<ep8wbqWkE HA.2500@TK2MSFT NGP09.phx.gbl>. ..[color=darkred]
> > > > Andrew,
> > > > I haven't done a lot of stack implementation, but my general[/color]
> > understanding[color=darkred]
> > > > is that one use of a stack is for storing procedure variables and[/color][/color][/color]
memory[color=blue][color=green][color=darkred]
> > > > locations while processors call other procedures. All of the current
> > > > procedure variables get stuffed onto the stack to reserve their[/color][/color][/color]
value,[color=blue][color=green]
> > along[color=darkred]
> > > > with the memory location to resume from, and the process continues[/color]
> > execution[color=darkred]
> > > > at the new memory location implied by the call. The new procedure[/color][/color][/color]
may[color=blue][color=green]
> > itself[color=darkred]
> > > > call another procedure and store its info on the same stack, and so[/color][/color][/color]
on.[color=blue][color=green][color=darkred]
> > > > Eventually the last procedure completes, returns control to the[/color][/color][/color]
calling[color=blue][color=green][color=darkred]
> > > > procedure which pops its variables from the stack, eventually[/color][/color][/color]
completes,[color=blue][color=green][color=darkred]
> > > > returns control, pops variables, etc. At least that is the myth I[/color][/color][/color]
carry[color=blue][color=green][color=darkred]
> > > > around in my head. There are other uses for stacks, as in parsing[/color]
> > streams of[color=darkred]
> > > > input. I am sure you can find more academic explanations.
> > > >
> > > > I can envision using a VB Collection for a stack, which, as a[/color][/color][/color]
practical[color=blue][color=green][color=darkred]
> > > > matter, would store VB objects in an order that could be controlled[/color][/color][/color]
with[color=blue][color=green][color=darkred]
> > > > indexes. I write a lot of business and engineering software and I do[/color][/color][/color]
not[color=blue][color=green][color=darkred]
> > > > remember implementing something I would really call a stack. Linked[/color]
> > lists,[color=darkred]
> > > > b-trees, arrays, other data structures, some may have been used like[/color][/color][/color]
a[color=blue][color=green]
> > stack[color=darkred]
> > > > 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[/color][/color][/color]
often[color=blue][color=green]
> > is[color=darkred]
> > > > patching together encapsulated data types (objects), data streams[/color][/color][/color]
and[color=blue][color=green]
> > whole[color=darkred]
> > > > applications using higher level languages.
> > > >
> > > > My $0.02,
> > > > Bob
> > > >
> > > > "Andrew" <hooksie2@hotma il.com> wrote in message
> > > > news:9dfb6bbd.0 409021606.6a1fa 1de@posting.goo gle.com...
> > > > > Last night I was reading about implementing my own stack. The[/color][/color][/color]
example[color=blue][color=green][color=darkred]
> > > > > given pushes items on and off the stack at the start and end of[/color][/color][/color]
each[color=blue][color=green][color=darkred]
> > > > > 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[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > > object on the stack at the start of every public procedure etc. in[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > > class and pop it off at the end? I can't see how else you can[/color][/color][/color]
know[color=blue][color=green][color=darkred]
> > > > > which object is active - or is this not normally a situation where[/color][/color][/color]
a[color=blue][color=green][color=darkred]
> > > > > stack is employed?
> > > > >
> > > > > Thanks in advance,
> > > > > Andrew[/color][/color][/color]

[Steve Gerrard]

Re: When to use a stack?


"Andrew" <hooksie2@hotma il.com> wrote in message
news:9dfb6bbd.0 409040153.6d597 b75@posting.goo gle.com...
| To clarify...
| First up - I am working with vba running in xl.
| |
| 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.
|

I've been following this thread, waiting for something interesting to
pop up. Then you mentioned pipe pressures, a subject I mess with at
work, and my ears perked up.

On the stack question: an example of when you might need a stack would
be if you had a string of multiple pipe, and you had to work your way up
the chain to find a starting pressure, then work your way back down to
calc the pressure in each pipe, or something of that sort.

Not particularly likely, but possible for certain kinds of calculations.
You would push each pipe onto a stack, then go on to the next one, until
you were ready to turn around. Then you would pop each pipe off of the
stack, process it, and continue until the stack was empty again.

On the Inlet vs Outlet: you say that either the outlet or inlet pressure
can be specified, and the other is to be calculated. I think you are
saying that once one is specified, you then want to block users from
trying to specify the other. If you really want to do that, you could
use a flag of some sort inside of MyPipe to keep track of which one is
entered and which one is calculated.

My own view would be that if the user specifies the inlet pressure, you
calculate the outlet pressure. If they then try to specify the outlet
pressure, you happily calculate the new inlet pressure for them,
replacing what they entered. If users don't get that they can only
specify one, you add a checkbox or something so they have to indicate
which one they want to enter.

[Andrew]

Re: When to use a stack?

Hi Tom,

Thanks again for the reply.
Your example of multiple choices - some sort of search tree - makes
more sense to me. The thing that I didn't quite get in the p440
example is that it talks about opening forms and then backing out of
them in the opposite order. When I've done this before I've just left
the calling form open and once the called form closes there you are
again. The same is true for procedures because once one is completed
you always return to the one that called it anyway. I guess if you
were dealing with a lot of forms maybe you would want to close the
calling form and then open it again upon exiting the called form to
save memory?

In terms of my specific problem it seemed more robust to keep the
tracking of value sources internal to the objects rather than creating
a public class attribute. I guess that still leaves the global
variable option...

Perhaps the most elegant solution would be:[color=blue][color=green]
>>cStream<<[/color][/color]
Public Property Let Pressure(NewVal ue As Single, Optional Source As
Integer)
OR
Public Property Let Pressure(NewVal ue as CustomType)
Where CustomType is defined as:
MyValue As Single
Source As Integer

But I can't get either of these to work.

On the other hand, if I could access the vba internal stack that would
be even better but apparently that's not possible.

Thanks,
Andrew


"Tom Ogilvy" <twogilvy@msn.c om> wrote in message news:<uFKdsYpkE HA.3372@TK2MSFT NGP09.phx.gbl>. ..[color=blue]
> On pg 440 they tell you why you might want to use a stack. In your example,
> I don't see any match to using a stack. Your explanation for an application
> appears asynchronous - having no set pattern or sequence. A stack is used
> when a sequential path is followed and then reversed. I would see a stack
> storage paradigm being applicable to a search, such as a depth first search
> where your confronted with multiple choices (as to path) along the way
> [basically a tree structrue]. When you reach the bottom of one path, you
> would walk backup to the next juncture. This would involve pushing and
> popping information on the stack. You would always want the information for
> the last node visited, which the stack provides. The stack is basically a
> LIFO queue. Now if you were traversing some type of pipe network, then
> perhaps a stack would be appropriate.
>
> That said, you do say you want to know how the value was set. I think you
> would have to have all your code that could set the value, update you stack.
> Then your procedure could check the stack to see how the the variable was
> set. However, if you don't need to move back "up" the stack, but only know
> about the most recent setting, then a global variable, class attribute, or
> similar should add all the functionality you need
>
> Unfortunately, when you mention stack, most people immediately focus on the
> calling stack which uses the stack storage paradigm. Thus Dana has shown
> you how to overflow that stack.
>
>
>
> --
> Regards,
> Tom Ogilvy
>[/color]

[Andrew]

Re: When to use a stack?

Hi Steve,

Thanks for your thoughts.
[color=blue]
> On the stack question: an example of when you might need a stack would
> be if you had a string of multiple pipe, and you had to work your way up
> the chain to find a starting pressure, then work your way back down to
> calc the pressure in each pipe, or something of that sort.[/color]

I think provided the pipes all had pointers to one another you
wouldn't need a stack but I guess if they didn't, or if they only had
pointers in one direction, then that would be essential.
[color=blue]
> On the Inlet vs Outlet: you say that either the outlet or inlet pressure
> can be specified, and the other is to be calculated. I think you are
> saying that once one is specified, you then want to block users from
> trying to specify the other. If you really want to do that, you could
> use a flag of some sort inside of MyPipe to keep track of which one is
> entered and which one is calculated.[/color]

That's exactly what I want to do. The problem is that I'd like to set
that flag internally rather than having to go
Outlet.Pressure =10
Outlet.Pressure Source = 1 (eg for calculated)
I wrote some other ideas on this in my reply to Tom.

In this case there is a bit of a risk that someone using my stream and
pipe objects to write their own code might overwrite the source value.
In any case there is no need for them to set a value so I would
rather them not have the option of doing so (less confusing).

[color=blue]
> My own view would be that if the user specifies the inlet pressure, you
> calculate the outlet pressure. If they then try to specify the outlet
> pressure, you happily calculate the new inlet pressure for them,
> replacing what they entered. If users don't get that they can only
> specify one, you add a checkbox or something so they have to indicate
> which one they want to enter.[/color]

I think this would be okay for a simple stream-pipe-stream set up on a
userform. But I want to be able to link an number of objects
together, for example: stream-pipe-stream-pump-stream-pipe-stream.
As the cases get more complicated there is a higher chance of
inadvertently overspecifying the problem and the pressure value that
would preside would just be the last one to be set - could get a bit
nasty to untangle.

[Tushar Mehta]

Re: When to use a stack?

Specific to your problem...

How have you implemented the In/Outlet and the Pipe entities? Are
Inlet and Outlet members of the same class? I assume Pipe is a
separate class. Would that be correct?

Suppose the In/Outlets are members of the class InOutLet. Then, that
class module might contain something like:

Option Explicit

Dim PressureBasedOn As Integer, dPressure As Double
Const cPressureSpecif ied As Integer = 1, _
cPressureCalcul ated As Integer = 2, _
cPressureUnknow n As Integer = 0

Property Get Pressure() As Double: Pressure = dPressure: End Property
Property Let Pressure(ByVal uPressure As Double)
Select Case PressureBasedOn
Case cPressureUnknow n:
dPressure = uPressure
PressureBasedOn = cPressureSpecif ied
Case cPressureSpecif ied: dPressure = uPressure
Case cPressureCalcul ated:
'Set error condition vis-a-vis specifying a calculated value
MsgBox "Cannot specify a calculated value!"
Case Else:
'System integrity error; PressureBasedOn has unexpected value!
End Select
End Property

Public Sub calculatePressu re(ByVal StartPressure As Double, _
ByVal PressureDrop As Double)
Select Case PressureBasedOn
Case cPressureUnknow n:
dPressure = StartPressure + PressureDrop
PressureBasedOn = cPressureCalcul ated
Case cPressureSpecif ied:
'Set error condition vis-a-vis calculating a specified value
MsgBox "Cannot calculate a specified value"
Case cPressureCalcul ated:
dPressure = StartPressure + PressureDrop
Case Else:
'System integrity error; PressureBasedOn has unexpected value!
End Select
End Sub

For test purposes, use something like:

Option Explicit

Sub testIt()
Dim x As New InOutLet
x.Pressure = 10
x.calculatePres sure 10, 1
MsgBox x.Pressure
Set x = New InOutLet
x.calculatePres sure 10, 1
x.Pressure = 10
MsgBox x.Pressure
End Sub


--
Regards,

Tushar Mehta

https://www.tushar-mehta.com

Excel, PowerPoint, and VBA add-ins, tutorials
Custom MS Office productivity solutions

In article <9dfb6bbd.04090 40153.6d597b75@ posting.google. com>, hooksie2
@hotmail.com says...[color=blue]
> 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" <twogilvy@msn.c om> wrote in message news:<#REx4kckE HA.524@TK2MSFTN GP15.phx.gbl>.. .[color=green]
> > 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.visua l.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" <hooksie2@hotma il.com> wrote in message
> > news:9dfb6bbd.0 409030532.678ce 76e@posting.goo gle.com...[color=darkred]
> > > 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.Cal ler 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" <rprgrmr@yahoo. com> wrote in message[/color]
> > news:<ep8wbqWkE HA.2500@TK2MSFT NGP09.phx.gbl>. ..[color=darkred]
> > > > Andrew,
> > > > I haven't done a lot of stack implementation, but my general[/color]
> > understanding[color=darkred]
> > > > 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,[/color]
> > along[color=darkred]
> > > > with the memory location to resume from, and the process continues[/color]
> > execution[color=darkred]
> > > > at the new memory location implied by the call. The new procedure may[/color]
> > itself[color=darkred]
> > > > 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[/color]
> > streams of[color=darkred]
> > > > 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[/color]
> > lists,[color=darkred]
> > > > b-trees, arrays, other data structures, some may have been used like a[/color]
> > stack[color=darkred]
> > > > 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[/color]
> > is[color=darkred]
> > > > patching together encapsulated data types (objects), data streams and[/color]
> > whole[color=darkred]
> > > > applications using higher level languages.
> > > >
> > > > My $0.02,
> > > > Bob
> > > >
> > > > "Andrew" <hooksie2@hotma il.com> wrote in message
> > > > news:9dfb6bbd.0 409021606.6a1fa 1de@posting.goo gle.com...
> > > > > 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[/color][/color]
>[/color]

[Tushar Mehta]

Re: When to use a stack?

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

https://www.tushar-mehta.com

Excel, PowerPoint, and VBA add-ins, tutorials
Custom MS Office productivity solutions

In article <9dfb6bbd.04090 30532.678ce76e@ posting.google. com>, hooksie2
@hotmail.com says...[color=blue]
> 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.Cal ler 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" <rprgrmr@yahoo. com> wrote in message news:<ep8wbqWkE HA.2500@TK2MSFT NGP09.phx.gbl>. ..[color=green]
> > 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" <hooksie2@hotma il.com> wrote in message
> > news:9dfb6bbd.0 409021606.6a1fa 1de@posting.goo gle.com...[color=darkred]
> > > 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[/color][/color]
>[/color]

[Steve Gerrard]

Re: When to use a stack?

(comments in line)

"Andrew" <hooksie2@hotma il.com> wrote in message
news:9dfb6bbd.0 409042027.7ec9b e73@posting.goo gle.com...
| Hi Steve,
|
| Thanks for your thoughts.
|
| I think provided the pipes all had pointers to one another you
| wouldn't need a stack but I guess if they didn't, or if they only had
| pointers in one direction, then that would be essential.
|

I agree you usually wouldn't need one.Use of stacks in programming with
objects is generally fairly limited. Tushar had one good example in one
of his posts, with nested slide shows.

| That's exactly what I want to do. The problem is that I'd like to set
| that flag internally rather than having to go
| Outlet.Pressure =10
| Outlet.Pressure Source = 1 (eg for calculated)
| I wrote some other ideas on this in my reply to Tom.
|

Assuming that MyPipe knows its inlet from its outlet, I would have kept
the flag inside of MyPipe, with a private variable mCalcedEnd:
Outlet.Pressure = 10
mCalcedEnd = 2 'outlet is calced
or, if the inlet gets calced,
Inlet.Pressure = 10
mCalcedEnd = 1 'inlet is calced

| In this case there is a bit of a risk that someone using my stream and
| pipe objects to write their own code might overwrite the source value.
| In any case there is no need for them to set a value so I would
| rather them not have the option of doing so (less confusing).
|

The situation to anticipate is that the user changes their mind. They
might enter an inlet pressure, look at the result, and realize that they
want to enter the outlet pressure instead.

| I think this would be okay for a simple stream-pipe-stream set up on a
| userform. But I want to be able to link an number of objects
| together, for example: stream-pipe-stream-pump-stream-pipe-stream.
| As the cases get more complicated there is a higher chance of
| inadvertently overspecifying the problem and the pressure value that
| would preside would just be the last one to be set - could get a bit
| nasty to untangle.

Yes, it does get a bit more complicated. I have dealt with a similar
task involving calculations with survey points. Depending on which
things are entered by the user, it has to calculate stations,
coordinates, elevations, and angles at every point.

I think there are two key things to making this work on a robust level
that can handle a wide variety of situations.

1. The individual objects (stream, pipe, pump, etc), should have two
sets of properties: the EnteredValues, and the CalcuatedValues . So for
instance you would have both EnteredPressure and CalculatedPress ure for
each object. Each object keeps track of whether or not it has an entered
pressure.

2. Perform the calculations at the collection or list level, not within
any of the individual objects. So instead of MyPipe responding to a
change in its inlet pressure, the PipeLineList object responds to a
change, and recalculates the whole line, or the affect portion.

During the re-calculation, the user-entered values are simply copied to
the calculated values of the objects, unless they are in conflict with
other entries. The result is that the calculated values for all objects
show the final result for the whole line.

[Andrew]

Re: When to use a stack?

Steve, Tushar,

Thanks alot for the time and effort you've put into your responses. I
have mucked around with the 'Property Let' statement some more and
finally figured out how optional parameters work, ie.

Public Property Let Pressure(Option al Source as Integer = 1, Value As
single)

This is quite nice because most people typing "Stream.Pressur e = 100"
from a std module will likely not even notice the optional "Source"
parameter. If they do then I will enumerate the constants (+ provide
help) so that shouldn't provide too much confusion. However, when
setting pressure from some other object I can pass source and store it
in the receiving object (after checking for inconsistencies ). This
will avoid having to keep track of the active object external to the
objects themselves.

In case you're interested my code will look something like:
[color=blue][color=green]
>> clsPipe <<[/color][/color]
Private With Events p_objStrmIn As clsStream
Private With Events p_objStrmOut As clsStream

Private Sub objStrmIn_Press ureChange()
' try to calculate dP - If successful (ie. all other rqd values
available)...
p_objStrmOut.Pr essure(Source:= 2) = p_objStrmIn.Pre ssure + dP
' will need some additional checking since this will trigger the
outlet stream
' event
' objStrmOut will raise an error if there is a conflict in source
End Sub
Private Sub objStrmOut_Pres sureChange()
' As per above but calculate StrmIn pressure
End Sub
[color=blue][color=green]
>> clsStream <<[/color][/color]
Public Property Let Pressure(Option al Source as Integer = 1, Value As
single)
' Check for inconsistencies
' Store the value & source where default source (=1) is user input
RaiseEvent PressureChange
End Property

This avoids needing the CalculatePressu re sub. Pressure is returned
via the same attribute whether calculated or input.

Thanks for all the input and thanks for the powerpoint example of
stacks - can relate to that one.

Andrew

Tushar Mehta <tmUnderscore20 0310@tushar-mehta.SeeOhEm> wrote in message news:<MPG.1ba50 a28c10e7d979899 38@news-server.rocheste r.rr.com>...[color=blue]
> Specific to your problem...
>
> How have you implemented the In/Outlet and the Pipe entities? Are
> Inlet and Outlet members of the same class? I assume Pipe is a
> separate class. Would that be correct?
>
> Suppose the In/Outlets are members of the class InOutLet. Then, that
> class module might contain something like:
>
> Option Explicit
>
> Dim PressureBasedOn As Integer, dPressure As Double
> Const cPressureSpecif ied As Integer = 1, _
> cPressureCalcul ated As Integer = 2, _
> cPressureUnknow n As Integer = 0
>
> Property Get Pressure() As Double: Pressure = dPressure: End Property
> Property Let Pressure(ByVal uPressure As Double)
> Select Case PressureBasedOn
> Case cPressureUnknow n:
> dPressure = uPressure
> PressureBasedOn = cPressureSpecif ied
> Case cPressureSpecif ied: dPressure = uPressure
> Case cPressureCalcul ated:
> 'Set error condition vis-a-vis specifying a calculated value
> MsgBox "Cannot specify a calculated value!"
> Case Else:
> 'System integrity error; PressureBasedOn has unexpected value!
> End Select
> End Property
>
> Public Sub calculatePressu re(ByVal StartPressure As Double, _
> ByVal PressureDrop As Double)
> Select Case PressureBasedOn
> Case cPressureUnknow n:
> dPressure = StartPressure + PressureDrop
> PressureBasedOn = cPressureCalcul ated
> Case cPressureSpecif ied:
> 'Set error condition vis-a-vis calculating a specified value
> MsgBox "Cannot calculate a specified value"
> Case cPressureCalcul ated:
> dPressure = StartPressure + PressureDrop
> Case Else:
> 'System integrity error; PressureBasedOn has unexpected value!
> End Select
> End Sub
>
> For test purposes, use something like:
>
> Option Explicit
>
> Sub testIt()
> Dim x As New InOutLet
> x.Pressure = 10
> x.calculatePres sure 10, 1
> MsgBox x.Pressure
> Set x = New InOutLet
> x.calculatePres sure 10, 1
> x.Pressure = 10
> MsgBox x.Pressure
> End Sub
>
>
> --
> Regards,
>
> Tushar Mehta
> www.tushar-mehta.com
> Excel, PowerPoint, and VBA add-ins, tutorials
> Custom MS Office productivity solutions
>
> In article <9dfb6bbd.04090 40153.6d597b75@ posting.google. com>, hooksie2
> @hotmail.com says...[color=green]
> > 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" <twogilvy@msn.c om> wrote in message news:<#REx4kckE HA.524@TK2MSFTN GP15.phx.gbl>.. .[color=darkred]
> > > 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.visua l.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" <hooksie2@hotma il.com> wrote in message
> > > news:9dfb6bbd.0 409030532.678ce 76e@posting.goo gle.com...
> > > > 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.Cal ler 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" <rprgrmr@yahoo. com> wrote in message[/color][/color]
> news:<ep8wbqWkE HA.2500@TK2MSFT NGP09.phx.gbl>. ..[color=green][color=darkred]
> > > > > Andrew,
> > > > > I haven't done a lot of stack implementation, but my general[/color][/color]
> understanding[color=green][color=darkred]
> > > > > 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,[/color][/color]
> along[color=green][color=darkred]
> > > > > with the memory location to resume from, and the process continues[/color][/color]
> execution[color=green][color=darkred]
> > > > > at the new memory location implied by the call. The new procedure may[/color][/color]
> itself[color=green][color=darkred]
> > > > > 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[/color][/color]
> streams of[color=green][color=darkred]
> > > > > 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[/color][/color]
> lists,[color=green][color=darkred]
> > > > > b-trees, arrays, other data structures, some may have been used like a[/color][/color]
> stack[color=green][color=darkred]
> > > > > 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[/color][/color]
> is[color=green][color=darkred]
> > > > > patching together encapsulated data types (objects), data streams and[/color][/color]
> whole[color=green][color=darkred]
> > > > > applications using higher level languages.
> > > > >
> > > > > My $0.02,
> > > > > Bob
> > > > >
> > > > > "Andrew" <hooksie2@hotma il.com> wrote in message
> > > > > news:9dfb6bbd.0 409021606.6a1fa 1de@posting.goo gle.com...
> > > > > > 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[/color]
> >[/color][/color]

[Tushar Mehta]

Re: When to use a stack?

Hi Andrew,

If you are comfortable with the solution, go with it. Not many people
leverage that particular capability of a property. It sure can be a
powerful tool.

In this instance, I rejected that approach because it seemed to make
more sense to move the calculation of the pressure into the class
module rather than have each client duplicate that work. However, you
know your application better than I do and if it makes sense to you...

--
Regards,

Tushar Mehta

https://www.tushar-mehta.com

Excel, PowerPoint, and VBA add-ins, tutorials
Custom MS Office productivity solutions

In article <9dfb6bbd.04090 61644.14a3aa@po sting.google.co m>, hooksie2
@hotmail.com says...[color=blue]
> Steve, Tushar,
>
> Thanks alot for the time and effort you've put into your responses. I
> have mucked around with the 'Property Let' statement some more and
> finally figured out how optional parameters work, ie.
>
> Public Property Let Pressure(Option al Source as Integer = 1, Value As
> single)
>
> This is quite nice because most people typing "Stream.Pressur e = 100"
> from a std module will likely not even notice the optional "Source"
> parameter. If they do then I will enumerate the constants (+ provide
> help) so that shouldn't provide too much confusion. However, when
> setting pressure from some other object I can pass source and store it
> in the receiving object (after checking for inconsistencies ). This
> will avoid having to keep track of the active object external to the
> objects themselves.
>
> In case you're interested my code will look something like:
>[color=green][color=darkred]
> >> clsPipe <<[/color][/color]
> Private With Events p_objStrmIn As clsStream
> Private With Events p_objStrmOut As clsStream
>
> Private Sub objStrmIn_Press ureChange()
> ' try to calculate dP - If successful (ie. all other rqd values
> available)...
> p_objStrmOut.Pr essure(Source:= 2) = p_objStrmIn.Pre ssure + dP
> ' will need some additional checking since this will trigger the
> outlet stream
> ' event
> ' objStrmOut will raise an error if there is a conflict in source
> End Sub
> Private Sub objStrmOut_Pres sureChange()
> ' As per above but calculate StrmIn pressure
> End Sub
>[color=green][color=darkred]
> >> clsStream <<[/color][/color]
> Public Property Let Pressure(Option al Source as Integer = 1, Value As
> single)
> ' Check for inconsistencies
> ' Store the value & source where default source (=1) is user input
> RaiseEvent PressureChange
> End Property
>
> This avoids needing the CalculatePressu re sub. Pressure is returned
> via the same attribute whether calculated or input.
>
> Thanks for all the input and thanks for the powerpoint example of
> stacks - can relate to that one.
>
> Andrew
>
> Tushar Mehta <tmUnderscore20 0310@tushar-mehta.SeeOhEm> wrote in message news:<MPG.1ba50 a28c10e7d979899 38@news-server.rocheste r.rr.com>...[color=green]
> > Specific to your problem...
> >
> > How have you implemented the In/Outlet and the Pipe entities? Are
> > Inlet and Outlet members of the same class? I assume Pipe is a
> > separate class. Would that be correct?
> >
> > Suppose the In/Outlets are members of the class InOutLet. Then, that
> > class module might contain something like:
> >
> > Option Explicit
> >
> > Dim PressureBasedOn As Integer, dPressure As Double
> > Const cPressureSpecif ied As Integer = 1, _
> > cPressureCalcul ated As Integer = 2, _
> > cPressureUnknow n As Integer = 0
> >
> > Property Get Pressure() As Double: Pressure = dPressure: End Property
> > Property Let Pressure(ByVal uPressure As Double)
> > Select Case PressureBasedOn
> > Case cPressureUnknow n:
> > dPressure = uPressure
> > PressureBasedOn = cPressureSpecif ied
> > Case cPressureSpecif ied: dPressure = uPressure
> > Case cPressureCalcul ated:
> > 'Set error condition vis-a-vis specifying a calculated value
> > MsgBox "Cannot specify a calculated value!"
> > Case Else:
> > 'System integrity error; PressureBasedOn has unexpected value!
> > End Select
> > End Property
> >
> > Public Sub calculatePressu re(ByVal StartPressure As Double, _
> > ByVal PressureDrop As Double)
> > Select Case PressureBasedOn
> > Case cPressureUnknow n:
> > dPressure = StartPressure + PressureDrop
> > PressureBasedOn = cPressureCalcul ated
> > Case cPressureSpecif ied:
> > 'Set error condition vis-a-vis calculating a specified value
> > MsgBox "Cannot calculate a specified value"
> > Case cPressureCalcul ated:
> > dPressure = StartPressure + PressureDrop
> > Case Else:
> > 'System integrity error; PressureBasedOn has unexpected value!
> > End Select
> > End Sub
> >
> > For test purposes, use something like:
> >
> > Option Explicit
> >
> > Sub testIt()
> > Dim x As New InOutLet
> > x.Pressure = 10
> > x.calculatePres sure 10, 1
> > MsgBox x.Pressure
> > Set x = New InOutLet
> > x.calculatePres sure 10, 1
> > x.Pressure = 10
> > MsgBox x.Pressure
> > End Sub
> >
> >
> > --
> > Regards,
> >
> > Tushar Mehta
> > www.tushar-mehta.com
> > Excel, PowerPoint, and VBA add-ins, tutorials
> > Custom MS Office productivity solutions
> >
> > In article <9dfb6bbd.04090 40153.6d597b75@ posting.google. com>, hooksie2
> > @hotmail.com says...[color=darkred]
> > > 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" <twogilvy@msn.c om> wrote in message news:<#REx4kckE HA.524@TK2MSFTN GP15.phx.gbl>.. .
> > > > 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.visua l.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" <hooksie2@hotma il.com> wrote in message
> > > > news:9dfb6bbd.0 409030532.678ce 76e@posting.goo gle.com...
> > > > > 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.Cal ler 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" <rprgrmr@yahoo. com> wrote in message[/color]
> > news:<ep8wbqWkE HA.2500@TK2MSFT NGP09.phx.gbl>. ..[color=darkred]
> > > > > > Andrew,
> > > > > > I haven't done a lot of stack implementation, but my general[/color]
> > understanding[color=darkred]
> > > > > > 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,[/color]
> > along[color=darkred]
> > > > > > with the memory location to resume from, and the process continues[/color]
> > execution[color=darkred]
> > > > > > at the new memory location implied by the call. The new procedure may[/color]
> > itself[color=darkred]
> > > > > > 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[/color]
> > streams of[color=darkred]
> > > > > > 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[/color]
> > lists,[color=darkred]
> > > > > > b-trees, arrays, other data structures, some may have been used like a[/color]
> > stack[color=darkred]
> > > > > > 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[/color]
> > is[color=darkred]
> > > > > > patching together encapsulated data types (objects), data streams and[/color]
> > whole[color=darkred]
> > > > > > applications using higher level languages.
> > > > > >
> > > > > > My $0.02,
> > > > > > Bob
> > > > > >
> > > > > > "Andrew" <hooksie2@hotma il.com> wrote in message
> > > > > > news:9dfb6bbd.0 409021606.6a1fa 1de@posting.goo gle.com...
> > > > > > > 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
> > >[/color][/color]
>[/color]