Sequence of object re-init on Server Configuration Reloading

MIP
, , ,
1

If the Server Configuration Reloading command is issued in Smart Client, which is the exact close & reinit sequence for MIP objects?

In the Class Life Cycle explanation I found only this statement:

“The refresh process is not illustrated below, but it basically callis the Close() on all plug-ins, and Init() again after the new configuration is in place”

This is quite cryptic as I dont know which kind of classes are subject to closing and re-initialization, and which are completeley disposed and re-constructed again.

I presume that only ViewItemUserControls, PropertiesUserControls, BackgrounPlugin, SidePanlePlugins and OptionDialogPlugins are subject to Close() and Init() methods. Or are they also disposed and the Constructor is called again on new instances?

And the ViewItemManagers , ViewItemPlugin and PluginDefinition objects?

Is there any calling of their Close() / Init() methods during server configuration reload?

I would like to know which objects are disposed and which are closed and re-initialized, in order to be sure to avoid loading properties or calling methods or using object references not yet or no more valid.

2

Your plugin is unloaded during a Server Configuration Reloading

If you want to learn more try this as an experiment.

Make a plugin that does

EnvironmentManager.Instance.TraceFunctionCalls = true;

Enable Smart Client MIP logging. - https://force.milestonesys.com/support/articles/en_US/How_To/Enable-XProtect-Smart-Client-logging-automatically-and-manually

Do a Smart Client session where you do a Server Configuration Reloading and afterwards explore the MIP log.

3

@Bo Ellegård Andersen (Milestone Systems)​

I found what I think is the root cause of the behaviour I’m observing.

During standard SC startup the sequence of calls is:

PluginLoader ():MyPlugin loaded from:[C:\Program](file:C:/Program) Files\Milestone\MIPPlugins\MyPlugin\MyPlugin.dll

Calling:MyPlugin ():ViewItemPlugin.Init()

Calling:MyPlugin ():GenerateViewItemManager

Calling:MyPlugin ():Deserialize

Calling:MyPlugin ():PropertiesLoaded

Calling:MyPlugin ():GenerateViewItemWpfUserControl

Calling:MyPlugin ():GenerateViewItemUserControl

Calling:MyPlugin ():ViewItemUserControl.Init()

After the Server configuration reload

Calling:MyPlugin ():ViewItemUserControl.Close

Calling:MyPlugin ():Serialize

Error: PlatformViewItem ():Unable to identify parent of a ViewItem. FQID not initialized.

Calling:MyPlugin ():GenerateViewItemManager

Calling:MyPlugin ():Deserialize

Calling:MyPlugin ():GenerateViewItemWpfUserControl

Calling:MyPlugin ():GenerateViewItemUserControl

Calling:MyPlugin ():ViewItemUserControl.Init()

Calling:MyPlugin ():PropertiesLoaded

I still have to undestand which objects are Serialized and Deserialized.

However it seems that the PropertiesLoaded in ViewItemManager is called too late compared to the generation and initialization of the new ViewItemUserControl.

Is this the reason why we need to listen to PropertyChangedEvent and use this method to re-init the ViewItemUserControl (like in ServerSideCarrousel sample) and not thrust the Init call for filling completely the properties?

4

Yes.

I can see and agree that the order of events is better at startup than at “Server Configuration Reloading”