What can cause Generate User Event to block?

[avogadro5]

I have a large application with quite a lot of automated UI tasks, and I've noticed that when a menu is open on the menu bar of any VI (does not matter if it's custom or LabVIEW default), "Generate User Event" starts blocking until the menu bar is closed.

My understanding is this should never block in normal circumstances and should act like a queue. So what can cause Generate User Event to block and how do I avoid the blocking?

[paul_cardinale]

I suspect it's an OS issue dating back to Windows 95 (or earlier).  In MS world, a stuff gets blocked when a menu is open.

[Kyle97330]

Just to clarify, you're saying that the "Generate User Event" node itself, this one, has dataflow enter it but not exit while a menu is open?  It's not that the event structure just stops getting the event temporarily?

What OS and LabVIEW version are you using?

Is this something you can generate a working example of?  I tried to make a 1-VI version of what you're talking about and couldn't replicate it, so it may be a complex interaction of some kind in your large application.

Does this happen when compiled to an EXE or is it limited to the dev environment?

[Gregory]

I'm not seeing that behavior. In the attached example the counter keeps incrementing even when I click on the menu bar. Do you see differently?

[avogadro5]

---

@Kyle97330 wrote:

Just to clarify, you're saying that the "Generate User Event" node itself, this one, has dataflow enter it but not exit while a menu is open?  It's not that the event structure just stops getting the event temporarily?

I had convinced myself this is what I was seeing but I have now un-convinced myself. Should I accept this as a solution?

[Kyle97330]

Solutions are generally intended to be a way for someone who has the same problem to skip to the middle or end of the thread when they have the exact same issue described in the first post.  It's possible to mark one of your own posts as the solution if you end up fixing it yourself.

If there's a post that was helpful but not actually a solution, clicking the "Kudos" button is usually what people do.  It's like a Reddit upvote or a Facebook Like.

So in this case you might make another post saying what you actually found the problem to be, mark that as the solution, and then give Kudos to any posts that helped you get there along the way.

[avogadro5]

Well for posterity, multiple other things were blocking with menus open, specifically opening a reference to a reentrant VI and all FPGA control read/writes while in simulation mode. I worked around opening VI references because in this case I was able to keep the same reference and reuse it. This solution was stolen from vi.lib\ActorFramework\Time-Delayed Send Message\Time-Delayed Send Message.vi.

[BertMcMahan]

Ah, you got bit by the ol' UI thread issue. Read up on the UI thread and the root loop for some more info.

In the meantime, here is some more info:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000001Dd6ISAS&l=en-US

Basically, you need the UI thread to load a VI into memory. Opening a menu blocks the UI thread. You don't need the UI thread to launch a VI, just to load it, so you can load all of your VI's into memory ahead of time, or use a static VI reference like the article says.

[avogadro5]

+1 for the root loop mention, I have been abused by UI thread weirdness for years but never heard of that.