Private Local Request Bug in DQMH 7.1.0

[adkin]

Maybe this is only happening to me, but I've noticed a very strange bug when creating multiple Private Local Request events in a row. I did a bunch of messing around to try to determine as best I could when it was happening and if I could find an easy workaround - I did, and its weird.

Steps to Reproduce

1. Create a new project.
2. Create a cloneable Parent module - must be cloneable since local requests are only relevant here.
3. Create a singleton or cloneable Child module (bug occurs with both types).
4. Add the Child's Null Broadcast events to the parents event registration.
5. Add the Child's Did Init broadcast to the Parent's EHL.
6. Create the first new Private Local Request in the Parent. (You can delete the calling VI that is dropped by scripting to remove broken arrow)
7. Create a second Private Local Request in the Parent.

The Bug

At this point, I observe that the Child's Did Init broadcast that I setup to handle in Step 5 above has changed to it's Error Reported broadcast instead.

Some Observations

1. Always seems to jump down 2 in the list of Child broadcast events or hit the end. So if you register for something other than Did Init it will change to something other than Error Reported.
2. The same behaviour is observed with Private Local Request and Wait for Reply events and even when mixing the two Local Request types together.
3. You can save and close the project after creating the first Local Request and still observe the same bug after re-opening and creating the second Local Request.
4. If I close LabVIEW completely, I don't observe the bug.
5. Occurs in helper loops as well.
6. All events for all child modules in all loops of the Parent will be affected. This can actually be really annoying to fix and why I started trying to figure out a bit about it.

The Workaround

The workaround is extremely simple, but I can't even begin to understand why it works. After creating the first Local Request, simply drag and drop the Data Event Node from any case in the Event Structure. That's it. You can now create the second Local event and shouldn't observe the bug. This does have to be a mouse drag, you can't move it with arrow keys or it doesn't work. You can drag and drop it back to the exact same location and it works fine. You can drag it to a new location then Ctrl-Z to undo and it works fine. This extra step does need to be done after creating each Local Request or the next one will exhibit the same issue.

Let me know if anyone is able to reproduce this. Or if you know why it's happening in the first place?

Thanks,

Aaron

[joerg.hampel]

adkin,

thanks for the elaborate report. I can reproduce the behaviour you describe (sadly your work-around doesn't seem to work on my machine, also restarting LV doesn't change anything for me) and I've assigned issue #1013.

[adkin]

---

sadly your work-around doesn't seem to work on my machine, also restarting LV doesn't change anything for me

---

Sorry to hear that. I was hoping that part would at least help out some folks that are having the same issue.

Time to put those new CI pipelines to the test already!

[joerg.hampel]

You guys might have to hold your breath for a little longer. This behaviour is due to how LabVIEW handles event registration of arrays / clusters and there is not a simple fix we can see right now. We are currently weighing our options as to how we can redesign the framework to mitigate this. 

We apologise for the inconvenience!

[adkin]

Glad to hear you were at least able to identify the cause. I sort of figured it was more of a LabVIEW quirk than a DQMH issue considering the "workaround" that I posted about. Sorry to be the bearer of bad news on this one 😔

If you have a better understanding of what's causing it, is there any chance that there's some other more reliable exploit to use a workaround in the short term? You mentioned simply dragging and dropping the event node didn't work for you, but maybe there's something else that's more reliable for others as well.

[joerg.hampel]

I will surely keep y'all updated with any helpful tips and tricks if and when they come up during our investigation.