(comments in line)

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