I have a HorizontalMenu which is used for page navigation, setting the target to the desired Page URL required.
I have managed to capture this target in the event handler onItemClicked, so that I can do some custom scripting as well as the navigation.
This works for the top level items.
How can we get this working for any nested items? ie: sub items?
I notice that if i print out the "Event" object, it doesn't seem to fire the script for any submenu items..?
My code:
def runAction(self, event):
# if event.enabled:
# add your action handling code
system.perspective.print(str(event))
Result when clicking the sub-menu item of the 0th item in a Horizontal Menu:
18:05:11.818 [Browser Thread: 4f7e8df6-96ff-4eca-b3a7-90d8c703706f] INFO Perspective.Designer.Workspace -- {"label":"Menu Item","enabled":true,"target":"","path":[0]}
18:05:15.059 [Browser Thread: 4f7e8df6-96ff-4eca-b3a7-90d8c703706f] INFO Perspective.Designer.Workspace -- designer.LinkComponent: Navigation not allowed in the Designer
18:05:15.108 [Browser Thread: 4f7e8df6-96ff-4eca-b3a7-90d8c703706f] INFO Perspective.Designer.Workspace -- {"label":"Link to Google","enabled":true,"target":"http://www.google.com","path":[0,0]}
My logged results are 100% what I would expect to be logged for that sub-menu item.
Version 8.1.40.
Yea pretty much the same code..
if event.enabled:
custom.log.operAction("Page Change", "url", event.target, session=self.session.info)
# end if
system.perspective.print("menu-home/HorizontalMenu/onItemClicked - event: %s" % event)
JSON for item[4] which has 3 child items:
{
"enabled": true,
"target": "",
"items": [
{
"enabled": true,
"target": "/sander3/overview",
"items": [],
"icon": {
"path": ""
},
"label": "Sander 3",
"style": {
"classes": ""
}
},
{
"enabled": true,
"target": "",
"items": [],
"icon": {
"path": ""
},
"label": "Sander 4",
"style": {
"classes": ""
}
},
{
"enabled": true,
"target": "",
"items": [],
"icon": {
"path": ""
},
"label": "Sander 5",
"style": {
"classes": ""
}
}
],
"icon": {
"path": ""
},
"label": "Sanders",
"style": {
"classes": ""
}
}
I only get ONE entry in the browser console, and it is for the main "Sanders" button NOT the child button that controls navigation to "/sander3/overview".
menu-home/HorizontalMenu/onItemClicked - event: {"label":"Sanders","enabled":true,"target":"","path":[4]}
Interestingly, it shows up correctly for items that DON'T have a target set.
But not for the one button that DOES have a page target set..
menu-home/HorizontalMenu/onItemClicked - event: {"label":"Sander 5","enabled":true,"target":"","path":[4,2]}
When I use your provided JSON, as part of my 2th item, I do get the event.
07:55:37.537 [Browser Thread: 4f7e8df6-96ff-4eca-b3a7-90d8c703706f] INFO Perspective.Designer.Workspace -- designer.LinkComponent: Navigation not allowed in the Designer
07:55:37.562 [Browser Thread: 4f7e8df6-96ff-4eca-b3a7-90d8c703706f] INFO Perspective.Designer.Workspace -- {"label":"Sander 3","enabled":true,"target":"/sander3/overview","path":[2,0]}
I do also get the other events - regardless of the presence of a target value.
07:55:39.413 [Browser Thread: 4f7e8df6-96ff-4eca-b3a7-90d8c703706f] INFO Perspective.Designer.Workspace -- {"label":"Sanders","enabled":true,"target":"","path":[2]}
07:55:41.312 [Browser Thread: 4f7e8df6-96ff-4eca-b3a7-90d8c703706f] WARN Perspective.Designer.Workspace -- level: WARNING
message: "components.HorizontalMenu: No navigation target configured for menu item Sander 4"
line_number: 2
source: "http://latest-83-qa.docker.ia.local/res/perspective/js/PerspectiveClient.5fb8fda2274336eaf96c.js"
07:55:41.336 [Browser Thread: 4f7e8df6-96ff-4eca-b3a7-90d8c703706f] INFO Perspective.Designer.Workspace -- {"label":"Sander 4","enabled":true,"target":"","path":[2,1]}
07:55:43.220 [Browser Thread: 4f7e8df6-96ff-4eca-b3a7-90d8c703706f] INFO Perspective.Designer.Workspace -- {"label":"Sanders","enabled":true,"target":"","path":[2]}
07:55:44.837 [Browser Thread: 4f7e8df6-96ff-4eca-b3a7-90d8c703706f] WARN Perspective.Designer.Workspace -- level: WARNING
message: "components.HorizontalMenu: No navigation target configured for menu item Sander 5"
line_number: 2
source: "http://latest-83-qa.docker.ia.local/res/perspective/js/PerspectiveClient.5fb8fda2274336eaf96c.js"
07:55:44.860 [Browser Thread: 4f7e8df6-96ff-4eca-b3a7-90d8c703706f] INFO Perspective.Designer.Workspace -- {"label":"Sander 5","enabled":true,"target":"","path":[2,2]}
Could you look in your Gateway logs to see if any errors are being logged there?
Thanks for testing that. How frustrating that its being weird my end..
I am not getting anything obvious in the Gateway Logs, this is the only thing showing up which could be something..
But I note that the views its complaining about are in fact, in my project:
I've setup a brand new Menu from scratch, same behavior. Only sub items with NO target give me the print out from the event. Anything that navigates to a Page URL does not..
Interestingly, I also get the "missing view" warning on my new test view that has the new horizontal menu on it. So there must be something to that..
I can now replicate what you're encountering.
I think the problem might be that the navigation to the new page is occurring before the onItemClick Event executes, and so the page the Horizontal Menu belongs to no longer exists - therefore the onItemClick Event never occurs.
I'm reasonably certain this is indeed the problem because when I use the same component in a Docked View which persists, the expected event is logged.
The reason I was able to see the Event logged previously is because I didn't actually have the View in my project. Due to the way the Designer (and Session) handle these types of errors, the error was captured, logged, and I continued on - right into the onItemClick Event I expected to find.
I can see how this behavior might be undesirable, but I'm not sure if we can change it. I'll ask around as to our wiggle-room here.
Glad you could replicate, sad that it is not working.
Yes that is really, really, undesirable.. There's basically no way to do anything useful with this component then.
We can't even add custom properties to it to store the URL in another prop, and manually call the navigate function.. 
But what about all the other event handlers? Surely if you put in some mouse click events you'd expect them to be executed even if there is a target set to do some navigation?
Sounds like none of them that trigger the navigation action would work either?
Do you know if there is anything we can do to get this to work? We're going to have to re-think our entire navigation if we can't get script events firing.
which is the best certification authority?
I think you might be a bit lost? Perhaps you should start a new topic to ensure people find your question.
Hmm. Might be scripted question for spammers trying to establish an "innocent" user account. See identical question here:
I don't have a workaround at this point in time. I have opened a bug ticket to get this officially investigated/scrubbed. Hopefully they will be able to provide a workaround during that process. Any potential fix would likely take some time; I would prepare an alternative, though I suppose it's still not clear exactly why you need these events during a successful navigation anyway. Perhaps we could address the requirement of the event in lieu of a quick repair? How are these events being used in your project?
Thanks, appreciate it.
Basically we wanted to track navigation with custom operator action logging functions.
One of the main purposes for doing so was to create some "back" and "forward" buttons for the Workstation app.
We've developed our application to use pages so we're looking to track any changes to the pageURL.
I tried a few things last night such as page startup event script, but its not really what we need. I can't seem to find an in-built event handler that would be useful for such a thing, such as change of page URL/ path.
You can do back navigation with the navigateBack function, and forward with the corresponding navigateForward function. So all the tracking of URL changes would be useful for is auditing/bookkeeping; unless you need it for that, tracking URL changes is unnecessary.
Ah thanks for that, don't know how I missed that one.. 
One thing that might prevent this from doing what we want is how many times you can call it though?
The docs don't seem to mention that, do you know how many URLs it is retaining in the background to make it work?
If we were doing it manually we were hoping to store at least 10 (although that might be excessive..)
It requests the operation through the browser, so however much history the browser session (ie: Workspace session) has accumulated.
