Re: When to use a stack?
Hi again Tushar,
[color=blue]
> 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.[/color]
I just realised that this is more of a "hack" than I thought at first.
When I create my 'Property Get Pressure()' it also needs to contain
the same optional parameter as the Prop Let otherwise I get a comiler
error (makes sense I guess). So it seems the "other" parameters in a
Prop Let/Get are anticipated to be more to do with defining the state
of the main variable that is passed rather than being attributes in
their own right.
I had envisaged:
objStream.Press ure(Source:=cUP _STRM_OBJ) = 100
whereas infact the following would make more sense:
objStream.Press ure(ValueType:= cSOURCE) = cUP_STRM_OBJ
objStream.Press ure(ValueType:= cVALUE) = 100
This of course is not what I want though so I think I will stick with
the first (kind of "incorrect" ) line and then just ignore the Source
parameter in the Prop Get:
Property Get Pressure(Source as Integer) As Single
Pressure = x 'regardless of any source value passed
End
A little bit messy but no solution seems quite perfect to this
problem.
[color=blue]
>
> 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...
>[/color]
The pressure drop calculation certainly belongs in the pipe and not
the stream. Whether you use this to set the stream pressure in the
stream or from the pipe is up for choice. I don't like the public sub
CalculatePressu re because I think for a user it becomes unclear since
this is not a function that they would need to call. But, thinking
along similar lines I did consider raising a dP_Change event.
Trapping this in the stream is more or less the same as your
CalculatePressu re sub. What's not so neat is that then to actually
determine the stream pressure it has to go back through the pipe to
get the pressure of the stream further upstream of the pipe. Plus
StreamIn would also catch the event* - can be handled but... Seemed a
bit inefficient.
So then I started wondering about stacks - but you already know that
part ;)
* since streamIn can be streamOut of some other pipe even further
upstream.
Best regards,
Andrew
Hi again Tushar,
[color=blue]
> 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.[/color]
I just realised that this is more of a "hack" than I thought at first.
When I create my 'Property Get Pressure()' it also needs to contain
the same optional parameter as the Prop Let otherwise I get a comiler
error (makes sense I guess). So it seems the "other" parameters in a
Prop Let/Get are anticipated to be more to do with defining the state
of the main variable that is passed rather than being attributes in
their own right.
I had envisaged:
objStream.Press ure(Source:=cUP _STRM_OBJ) = 100
whereas infact the following would make more sense:
objStream.Press ure(ValueType:= cSOURCE) = cUP_STRM_OBJ
objStream.Press ure(ValueType:= cVALUE) = 100
This of course is not what I want though so I think I will stick with
the first (kind of "incorrect" ) line and then just ignore the Source
parameter in the Prop Get:
Property Get Pressure(Source as Integer) As Single
Pressure = x 'regardless of any source value passed
End
A little bit messy but no solution seems quite perfect to this
problem.
[color=blue]
>
> 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...
>[/color]
The pressure drop calculation certainly belongs in the pipe and not
the stream. Whether you use this to set the stream pressure in the
stream or from the pipe is up for choice. I don't like the public sub
CalculatePressu re because I think for a user it becomes unclear since
this is not a function that they would need to call. But, thinking
along similar lines I did consider raising a dP_Change event.
Trapping this in the stream is more or less the same as your
CalculatePressu re sub. What's not so neat is that then to actually
determine the stream pressure it has to go back through the pipe to
get the pressure of the stream further upstream of the pipe. Plus
StreamIn would also catch the event* - can be handled but... Seemed a
bit inefficient.
So then I started wondering about stacks - but you already know that
part ;)
* since streamIn can be streamOut of some other pipe even further
upstream.
Best regards,
Andrew
Comment