Our low level symbols like monitor, portA, printer, etc, are set to
ovwSymbolStatusSource - hence these symbols do represent different
states for the object. We use OVwSetStatusOnSymbol to set the status for
monitor, etc.
It is the parent symbol (node1) for the submap containing monitor, etc,
that has its source set to ovwCompoundStatusSource - this saves us
having to calculate a status for the node1 symbol.
When we use acknowledge on node1 and all symbols go green it suggests
ipmap is using OVwSetStatusOnObject which causes all symbols for the
object to go to the same status.
--
Robin
email: robin.james@thalesatm.com
tel: +44 (0) 1633-862020
fax: +44 (0) 1633-868313 --- Begin Message ---
95% all makes sense.
An exert from ovw.h:
* Symbol status source types.
*
* Status is represented on a per symbol basis. Thus, the status of an
* object can be different for different symbols representing the object.
* This allow the semantic context of a symbol in a particular submap to
* determine its status. In addition to status being per symbol, the
* configuration of the status source is also per symbol.
*
* ovwObjectStatusSource - Status for the symbol is set based on the
* status of the object, which is set using OVwSetStatusOnObject().
* ovwCompoundStatusSource - Status for the symbol is set based on the
* compound status of the object the symbol represents. Compound
* status for the object is determined by the status of the symbols
* in the child submap of object, using built-in, user-configurable
* status propagation rules.
* ovwSymbolStatusSource - Status for the symbol is set based on symbol-
* specific status, which is set using OVwSetStatusOnSymbol().
* (This allows applications to calculate their own compound status
* based on specific semantic rules in a particular context.)
-- Why did you chose ovwCompoundStatusSource?
"-- Your code extract
Is the ack submap something your code maintains?"
-- Thought I pulled all of that out of the snippet. Yes, I wrote an app to
maintain a separate submap that contains all of the currently Ack'd Objects
with their own Symbol. I ended up being very happy with it. All dynamic,
happened on the fly, fun to watch. I also added a pull-down to display/hide
the map. This gave the operators a 'quick' look into the currently ack'd
objects.
"-- Our proposed approach
We're trying a different solution by generating our own event on
selecting node1 with a new "own-ack" menu option. We will set the status
source to symbol and set the colour to user1status - if we set it to
acknowledge everything will go green because ipmap jumps in and does
what it has to when acknowledge is used.
On our new "own-unack" menu option we will set the node1 status source
back
to compound.
Hopefully this strategy will work."
-- This sounds like fun, please keep the list in the loop on how it works
out. The only potential problem I can think of is the API will not let you
set a symbols status that is currently a "reserved status", i.e. you cant
set a symbols status that is currently Acknowledged, hopefully this does not
apply to User1. I am not sure how that will effect you, but something I
remember coming across, but ovwUnknownStatus represents Unacknowledged
State.
"The tricky thing looks to be how to find out the symbol id for node1
when netview just tells you the object that has been selected."
-- Good question. I would assume the same way Netview knows which object to
do what with when you issue pull-down commands.
Best of luck,
JA
--
Robin
email: robin.james@thalesatm.com
tel: +44 (0) 1633-862020
fax: +44 (0) 1633-868313
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
--- End Message ---
|