Find Events.llb (for ctrl/ind/FPTerm/local var/ctrl ref)

[AristosQueue (NI)]

Author: wiebe@CARYA (for QuickDrop) and ported to shortcut menu by Darren (NI)

Provide a way to find event frames associated with a given control or indicator.

Attachement is saved in LabVIEW 2015. For install instructions, go here.

[vishots.com]

I have a suggestion for an enhancement. If there's only one event case found, then don't bring up the dialog. Just jump to the event case and show it.

[AristosQueue (NI)]

It's a floating window, not a dialog. It's meant to stay open to show the results. What if it opened the window and went ahead and highlighted the one case?

[huangjinghit]

Very useful function, thanks!

[X.]

There are a few UI "features" that may be worth mentioning:

- it will open the result window even if there is no match.

- if will prevent undoing a delete event case action if you look for the event you just deleted.

- for some reason, if you have events involving tabs, controls that are in these tabs and whose events you are looking for, will be listed below the events involving tabs in the result list (in other words, you are stuck with those tab events no matter what you do).

For this reason I am giving it 4 stars at this stage, as it is still a useful tool as is.

[parthabe]

Will it work for LV 2014? If yes, could someone post a downconverted version of the LLB? Thank you in advance!

[Darren]

Shortcut menu plug-ins are only supported in LabVIEW 2015 and later. However, the original tool was written as a Quick Drop Keyboard Shortcut plug-in, which you can download here. I believe this QD plug-in works in LabVIEW 2013 and later.

[X.]

More features attributed to this plugin (but might be due to something else) and this one, potentially very troublesome:

Using "Find Events" and double-clicking one of the hits to go to the event CLEARS THE UNDO STACK!

Example VI (with instructions) attached:

[Hooovahh]

According to Darren in a post on LAVA, performing scripting operations that isn't wrapped in a Undo Begin will cause the undo stack to be cleared out.  I suspect this is a bug in the code related to doing some scripting.

[X.]

I did try to look into the code, but there are some protected VIs (I commented on that on the thread by AQ giving instructions on not protecting VIs...), so I gave up.

I just wanted to say that the undo stack clearing is not limited to the case I had mentioned previously.

If anyone feels like fixing that problem, this would save a lot of potential trepidations to unsuspecting users (including me, as I will probably forget about this at a critical time).

[kosist90]

Nice and useful plugin!
Let me share idea for improvement - if one opens typedef, and clicks on controls there, "Find Events" option is available. But of course, no events could be there for this control. Maybe, it could be nice to filter out this menu option, if control is located not in the VI, but in control file type (*.ctl), and other similar files where Event Case could not be present logically.
Also, maybe plugin could first of all verify if VI has Event Structure at all, and display menu option just if Event Structure is present. If Event Structure is not found, menu option "Find Events" could be present, but grayed out.

[Mads]

FYI:
Just moved from LabVIEW 2022 to 2024Q3 and in 2024 the plugin seems to have lost its ability to jump to event cases.

If you double-click on an event in the list of found events references are invalid and throw error 1026 or 1055...I will have a look at how to fix it, but if someone has already done this perhaps they could post the fixed version?

[wiebe@CARYA]

I haven't been used this plugin myself, but if it's hard to fix (let me know here) I could try to regain interest in it.

[Mads]

You do not use it anymore?

I use(d) it all the time, it is great (thanks for making it). I wish the functionality was built into LabVIEW.

Debugging these plugins seem to be a challenge though(?). I set many of the VIs to show their panel when called e.g. to see what inputs and outputs they got, but most of them geit their front panels cleared by the surrounding system it seems(?). Adding breakpoints did not seem to work as normal either...So even though the event list dialog gets a list of events as it should the VIs generating that list do not show any outputs. For some reason the references get invalidated at some stage so double-clicking the event goes nowhere.

[wiebe@CARYA]

>You do not use it anymore?

I know, it's weird...

>Debugging these plugins seem to be a challenge though(?). I set many of the VIs to show their panel when called e.g. to see what inputs and outputs they got, but most of them geit their front panels cleared by the surrounding system it seems(?). Adding breakpoints did not seem to work as normal either...

These plugins are executed in another context. So, yes, debugging is hard.

For development, I you can debug quite easily by calling the plugin as a SubVI from the normal context.

However, I don't know if that's enough in this situation. These problems seem to come from the framework.

>Just moved from LabVIEW 2022 to 2024Q3 and in 2024 the plugin seems to have lost its ability to jump to event cases.

Something must have changed. I wander if other plugins are effected (I use Find All Uses a lot). If so, LabVIEW needs to be fixed. If not, the plugin might need to be adjusted to do things like Find All Uses does.

[crossrulz]

Yes, something got broken by stuff moving to LVAddons. Darren found it when I had problems with a QD plugin. I think it was fixed in Q3. The plugin I was using is here: Quick Drop Keyboard Shortcut - Create via_ignore Bookmark 

[Darren]

The issue in this plugin is different from the LVAddons one, and was discussed in a thread in the LabVIEW Champions forum. I sent Wiebe a private message with more details.

[Mads]

That is great Darren, thanks. It would be nice to have these changes openly documented/discussed though, then perhaps the whole community can contribute in the necessary follow-up work.

[Darren]

> It would be nice to have these changes openly documented/discussed though, then perhaps the whole community can contribute in the necessary follow-up work.

The issue was originally reported to NI via the private LabVIEW Champions forum, that's why the discussion took place there. I can add some more details here. In LabVIEW 2024 Q3, R&D made a change to more aggressively clean up references that are opened by right-click plugins. As a result of this change, we are no longer able to do things in a right-click Execute VI like pass object references to dynamically launched VIs, as this new clean up approach will automatically close those references behind the scenes.

I described the use cases that broke as a result of this change (including the plugin posted here, and others), but R&D currently feels that this new behavior in LV 2024 Q3 does more good than harm. Their guidance is to update plugins to use a different approach to share data between a plugin and a dynamically launched VI. In the case of Wiebe's plugin here, such a change might look like passing UIDs of referenced objects to the dynamically launched VI, as opposed to those object references themselves.

[Mads]

Ok. I first tried to send UIDs and Owner VI names to the dynamic list to be able to get a reference from there. That failed for some reason, but just moving the events list to the execute VI bypasses the reference invalidation issue. I can post an example of that fix here later unless Wiebe wants to make an official fix.

PS. It is a bit worrying that such changes are made to a public API like this without more of an effort to handle how it will potentially break and consequently discourage lots of nice tools and contributions from the community, especially if it just a matter of doing something slightly more "correct" and not adding more value to the users of LabVIEW (there might be some unknown value here of course, if so my apologies for not appreciating them yet)...In this case; the value of beng able to find related events 😉

[Mads]

Just moving the events list to the execute VI has one disadvantage compared to the dynamic approach; you cannot navigate into/edit any of the shown event cases until you have closed the plugin's event list because the GUI is still waiting for the plugin to close.That was not an issue when the dynamic event list VI as it would continue to run in parallell even though the plugin core had completed its execution.

So, you can use the list to move around (but then you have to find the plugin window again every time as it might get hidden), but you can no longer do anything with the highlighted cases until you actually close the plugin. Understanding that there is such a block is not intuitive though, so unless the dynamic approach is fixed it might make more sense to always close the plugin when a case has been selected and require the user to redo the find event action instead.

A possible compromise would be to have the execute window float. You can then double click multiple events to get a look at which is which, and do so without losing sight of the plugin window, but you still have to close the plugin window to unblock further navigation (be able to work on any of them).

[Mads]

I have uploaded two possible fixes here (not being able to attach anything to replies here as far as I know), one keeping the dynamically launched window and one using the execute VI:

https://forums.ni.com/t5/tkb/workflowpage/tkb-id/3044/article-id/4096

I have not used UIDs to get references to VIs before, but doing so here I managed get the dynamic solution to work as long as the owning VI is part of a project (open VI ref lacks the correct app instance if opened outside a projec..not sure how to get the right ref then) I had to do a trick though where I refresh the reference after the caller has finished as the original references seem to get invalidated by that even now that they are created based on the UID :-O. This version might need some more reference cleasning than it currently has...(?).

Putting everything in the execute VI instead to avoiding the issue of handing references to a dynamic VIs introduced with 2024, has as mentioned above its own downsides, but other than that that version works fine. 

[Petru_Tarabuta]

Hi Mads,

Thanks for your work on improving this tool. I used to use it regularly too - it's extremely useful. I haven't used it as much in the last few months, but I will probably use it again in the future.

The link above (https://forums.ni.com/t5/tkb/workflowpage/tkb-id/3044/article-id/4096) does not work for me. It displays "Page Error".

Kind regards,
Petru

[Mads]

Thanks Petru. You could try this (it seems to work even when I am logged out...):

https://forums.ni.com/ni/attachments/ni/3044/4096.2/2/Find%20Events%20%20Plugin%20-%20fixes%20for%20...

It is associated to a public draft that I now sent for approval as well, but if it is not accesible I can try to put it someplace else...

[Petru_Tarabuta]

I can confirm that:

1. The new link works. The zip file is downloaded as soon as the link is clicked.

2. The issue you reported a few days ago occurs on my machine too. Using the original implementation double-clicking on a line item does not do anything.

3. The Dynamic but only works for VIs in project fix found inside the zip file works on my machine. I have not tested the non-dynamic version. The vast majority of VIs I work with are inside projects, so I will just use the dynamic version.

Computer setup: LabVIEW 2024 Q3 24.3.2f2 (64-bit) on Windows 11

Thanks!

[Mads]

Thanks to some help from @Darren over on LAVA I was able to get the dynamic version to work for VIs both in and outside a project. The new fix is available here:

https://forums.ni.com/ni/attachments/ni/3044/4096.3/3/Find%20Events.llb

I had an event structure in the execute VI for debugging only that seems to be necessary to get the whole thing to work so for now I have kept that, uit does not affect the VI...I also seem to have to open VI references again in the background once the execute VI has finished, but OK...I do not close the application references I open in this fix so that might be a small leak...otherwise the dynamic version of the plugin now seems to work at least.