Custom Refresh Manager
- Last UpdatedNov 14, 2022
- 2 minute read
The database updates which are handled within the Flexible Explorer core code are generic and the performance of a flexible explorer control can be an issue for large projects and for complex Flexible Explorer Definitions. So it is recommended that for each Flexible Explorer Definition a Custom Refresh Manager is written in C# as part of the addin.
A Custom Refresh Manager has knowledge of the Flexible Explorer Definition and all database updates for the Flexible Explorer definition should be made as efficiently as possible.
For this example a Custom Refresh Manager would ignore database events (new, delete, change, change of owner) for all elements apart from EQUI and NOZZ elements. Further, all attribute changes for these elements could be ignored apart from a change of name, since this is the display name in this example.
If all database changes can be ignored then the performance of the tree is optimal.
The code snippet below (taken from the Flexible Explorer addin sample project) shows where the CustomRefreshManager is added to the code:

Given the database changes which have occurred the Custom Refresh Manager should set the refresh type for the Flexible Explorer Definition. This can be one of:
-
RefreshArguments.RefreshType = RefreshOperation.None;
-
RefreshArguments.RefreshType = RefreshOperation.NodesOnly;
-
RefreshArguments.RefreshType = RefreshOperation.NodesWithCollections;
-
RefreshArguments.RefreshType = RefreshOperation.WholeTree.
By selecting None the tree will not be refreshed at all, this means that deleted elements are still displayed in the tree, for example. The option WholeTree means that the whole of the tree will be refreshed; this option should be avoided for performance reasons.