SA_controls - treviewitem

Hi,

I extended the ExampleSA at some point to use the Equipment model for navigating.
For the treeview, I set datasource to "__EquipmentModel" and unticked checkboxes, but display alarms.
For the left click function I defined my own call "Nav_SetSelEquipment".

Which is like this :

FUNCTION Nav_SetSelEquipment(INT hTreeItem)
STRING sEquipment = MenuNodeGetProperty(hTreeItem, MENU_PROP_Equipment);

Debug_Trace("Treeview", " Nav_SetSelEquipment", "sEquipment = "+sEquipment, TRACE_Information);

Workspace_SetSelContext(sEquipment,"");
Workspace_SelectEquipment();

END

In my case the treeview was set in a static pane (on the left) and on the right there was a content pane with "AutofillContextMustMatch".
As a result the workspace functionality will make sure the panes follow the equipment context set.

Hope this helps.

Hi Ignatious,

To bind it against the Navigation menu, set the Dataource parameter of the tree genie to "Navigation" (no quotes) and add a left click handler.

The left click handler should be:

FUNCTION MenuTree_OnClick(INT hMenuItem)
_Navigation_RunCommandFromMenuHandle(hMenuItem, TRUE);
END

This will allow you to preserve navigation stack behaviour.

When you run that up you'll notice it all works - except for when a navigation occurs from something like a contextual change navigation e.g. navigate to equipment from an alarm on an alarm page.

To get that working, you need to add a cicode animation object to the pagethat contains your tree control. Make it class a function: MenuTree_SyncSelection.

The code of which is below.

Note: This is all from a workspace customisation topic I've been putting together so it has not gone through formal testing.

FUNCTION MenuTree_SyncSelection()
STRING sContext, sStartupContext;
STRING sCachedPrimaryPage;
STRING sCurrentPrimaryPage;
STRING sNavigationPath;
INT hMenuItem;


INT nWinCurr = WinNumber();
INT nTreeviewAN = DspGetAnFromName("Treeview");

// Check if the current page has changed from the cached page
sCachedPrimaryPage = PageGetStr(g_sCachedPrimaryDisplayPage, nWinCurr);
sCurrentPrimaryPage = PageGetStr(g_sPrimaryDisplayPage, Workspace_GetWindow());

IF (sCachedPrimaryPage = sCurrentPrimaryPage) THEN
// It hasn't changed, so leave selection as is
RETURN;
END

// Update the cache with the new current page
PageSetStr(g_sCachedPrimaryDisplayPage, sCurrentPrimaryPage, nWinCurr);

IF (sCurrentPrimaryPage <> "") THEN
// Find the menu item corresponding to the current page
hMenuItem = _Navigation_FindMenuItem(sCurrentPrimaryPage);
IF (hMenuItem <> BAD_HANDLE) THEN
sNavigationPath = _Menutree_GetNavigationPath(hMenuItem);
Treeview_Locate(nTreeviewAN, sNavigationPath);
END
END
END


PRIVATE
STRING
FUNCTION _Menutree_GetNavigationPath(INT hMenuHandle)
STRING sMenuName;
STRING sMenuPath;
INT hMenuItem = hMenuHandle;

WHILE (hMenuItem <> BAD_HANDLE) DO
sMenuName = MenuNodeGetProperty(hMenuItem, 0);

IF (sMenuName = g_sNavigation_CoreNavigationMenu OR sMenuName = g_sNavigation_HeaderBarMenu OR sMenuName = g_sNavigation_EquipmentModel) THEN
// Don't add the root items "Navigation", "HeaderBar" or "__EquipmentModel" to the path
hMenuItem = BAD_HANDLE;
ELSE
// Add the item to the path
IF (sMenuPath <> "") THEN
sMenuPath = sMenuName + "." + sMenuPath;
ELSE
sMenuPath = sMenuName;
END

// Move to parent item
hMenuItem = MenuGetParent(hMenuItem);
END
END

RETURN sMenuPath;
END

that's good. however i was also after the requirement to have the page alarms updated on the treeview. i compared the code between the dashboard page navigation and the tree view and note that the treeview performs the alarm counts for equipment presently. is there an equivalent code that will update the alarm counts for the pages? it will be good if this is supported. we are implementing our master page a little different to the standard one that came with the include project.

No there is not. it is certainly something we have discussed internally, but it has not on the immediate backlog. As the tree supports up to about 14 levels deep you would have to handle multi parent summarising etc which would require a different counting system. Also I would advise taking care of the number of alarm counts that would yield.