Filter a branch of the Equipment Tree

Hi Bas,

That'll be a fun project. I haven't done this one myself. But I can give you some pointers of where I would start... or not start.

What I wouldn't do

• Piggybacking/modifying the search system. You are better off keeping that so operators can still search within your sub-trees of the equipment model
• Directly modify the "RootNodeHandle" meta data property of the treeview without handling its uses first. Although tempting and might look like it works, this handle gets "released" when reloads occur via the model watcher. This property holds the root handle to the data source menu tree (what is used to hold the equipment model in memory). Regardless, this is the starting point for a solution.

How you could approach it

Right up front, you would be looking at a copy of the treeview.ci and treeview genie imo. As soon as you do that you will need to assess whether anything else that uses the currently shipped treeview is going to get your sweet upgrades (e.g. Trend page which uses treeview public api)

I'm going to ignore the complications of duplicating or replacing include code in my notes below as you are well versed in those ramifications.

Currently, Treeview_GetMenuHandle is used for two purposes:

1. Storing the page node so it can be freed later
2. Telling the treeview which node to use for the model presentation in the treeview

It is retrieving the "RootNodeHandle" mentioned earlier. That last point is useful, ideally we want to tell it to point somewhere else in the tree. If we could do that, then all the treeview functionality would be intact and you would be pointing at your sub branch.

But, because of pt 1, we can't just do anything nasty like write over the top of RootNodeHandle. Instead we need to divide this into those two distinct parts.

I would:

• Make a copy of Treeview_GetMenuHandle() and rename to Treeview_GetMenuRootHandle().
• Modify _Treeview_Reload to use the new Treeview_GetMenuRootHandle()
• Add a new metadata property "BranchNodeHandle" to the genie to accept a "path" within the model e.g. "Company.TopMilk.Bottling".
• Modify  _Treeview_RetrieveItemsTask to call MenuGetNodeByPath to resolve the path and store that in BranchNodeHandle
• Modify Treeview_GetMenuHandle to return that branch handle
• Add a new function which can dynamically set the BranchNodeHandle which you will call with your buttons. Make sure you call _Treeview_UpdateNodes, within that.

Hopefully that is it.

Let me know how you go.

Cheers,

bradley

Hi Bas,

That'll be a fun project. I haven't done this one myself. But I can give you some pointers of where I would start... or not start.

What I wouldn't do

• Piggybacking/modifying the search system. You are better off keeping that so operators can still search within your sub-trees of the equipment model
• Directly modify the "RootNodeHandle" meta data property of the treeview without handling its uses first. Although tempting and might look like it works, this handle gets "released" when reloads occur via the model watcher. This property holds the root handle to the data source menu tree (what is used to hold the equipment model in memory). Regardless, this is the starting point for a solution.

How you could approach it

Right up front, you would be looking at a copy of the treeview.ci and treeview genie imo. As soon as you do that you will need to assess whether anything else that uses the currently shipped treeview is going to get your sweet upgrades (e.g. Trend page which uses treeview public api)

I'm going to ignore the complications of duplicating or replacing include code in my notes below as you are well versed in those ramifications.

Currently, Treeview_GetMenuHandle is used for two purposes:

1. Storing the page node so it can be freed later
2. Telling the treeview which node to use for the model presentation in the treeview

It is retrieving the "RootNodeHandle" mentioned earlier. That last point is useful, ideally we want to tell it to point somewhere else in the tree. If we could do that, then all the treeview functionality would be intact and you would be pointing at your sub branch.

But, because of pt 1, we can't just do anything nasty like write over the top of RootNodeHandle. Instead we need to divide this into those two distinct parts.

I would:

• Make a copy of Treeview_GetMenuHandle() and rename to Treeview_GetMenuRootHandle().
• Modify _Treeview_Reload to use the new Treeview_GetMenuRootHandle()
• Add a new metadata property "BranchNodeHandle" to the genie to accept a "path" within the model e.g. "Company.TopMilk.Bottling".
• Modify  _Treeview_RetrieveItemsTask to call MenuGetNodeByPath to resolve the path and store that in BranchNodeHandle
• Modify Treeview_GetMenuHandle to return that branch handle
• Add a new function which can dynamically set the BranchNodeHandle which you will call with your buttons. Make sure you call _Treeview_UpdateNodes, within that.

Hopefully that is it.

Let me know how you go.

Cheers,

bradley