Item MapIcon changes unexpextedly

MIP
, , ,
1

Hey,

we have this ItemNode Called

“Inputs” from “InputsKind”

and his childrens called “InputX” all from “InputKind”

when adding or remove any of childrens item from “InputKind” using DeleteItemConfiguration (from Managment usercontrol/managment)

just wipe item icon shown on smart map.

i.e.

Inputs.GetChildrens();

returnes Input1,Input2,Input3 etc.

after icons update while smartClient is open

try remove Input3 with the DeleteItemConfiguration Method,

the Input1,Input2 and all the remaining items is geting some kind of icon reset to the default icon defined in the PluginDefinition.

To Inputs there another siblin called Outputs.

Outputs holds OutputX items.

the icon reset for Inputs does no effect the Outputs and Output Items icon.

is there another way i should do it?

Thank You,

Or

2

Let me clarify one thing, does this happen on a Smart Map or Map? Because we tested the issue and saw the symptom only on a MAP, not Smart Map.

3

Thanks for.your relpy,

We have this issue on the MAP, we havnt checked this yet with the smart map.

​

Is there a fix or a workaround so we could use this feature without loosing settings like the MapIcon(also effect the Item.ContextMenu being flushed also).

​

Thanks.

Or​

4

It seems a bug because we could see the issue. Milestone Development will start an investigation, let me get back to you when I receive a news from them.

5

We found that this is a combination of how configuration changes are handled in the Event Server and how at least the Sensor Monitor sample is implemented.

Whenever there is a change to any item of a specific kind a notification will be sent to Event Server and it will reload all items of this kind. Unfortunately even though SensorMonitor sample persists the state of the sensors (in static SensorItem.SensorActiveState dictionary) the icon is a property on the item itself and will thus be reset when the configuration is reloaded.

So you need to ensure that the current icon is also persisted when the items are related.

We will fix this in the SensorMonitor sample by overriding the SensorItem.MapIconKey with the following code and no longer set the icon from SensorMonitorSensorItemManager (as it will now be controlled by the state instead):

   public override Guid MapIconKey

   {

       get

       {

           if (SensorActiveState.ContainsKey(FQID.ObjectId) && SensorActiveState\[FQID.ObjectId\])

           {

               return SensorMonitorDefinition.SensorMonitorSensorActivated;

           }

           else

           {

               return SensorMonitorDefinition.SensorMonitorSensorKind;

           }

       }

       set { } // do nothing

   }