LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Matt_AM

LabVIEW should have a native popup message that doesn't hang the code

Status: New

I think LabVIEW should have something like the dialog VIs that acts as a popup where the vi displays a message to the user but doesn't hang up code and wait on the user to press a button.

 

An example case is a state machine that has error checking built in errors out.  Instead of creating a more complex error handling scheme to display the state machine errored out and heres why then shutdown the state machine, you could instead drop this async popup in the state with the message to display the error occurred then have the state machine shutdown like normal.  This way, the user knows "the state machine shutdown for X reason" while the state machine also goes into a safe state.  

 

I think the async popup is easier to trace since the error message is located in that section that detected the error vs having some sort of store an error string then in the shut down case read if there is an error and if so display the error once the station is already shutdown.  Additionally, you cold see where all asnyc message blocks are via dropping one in your code then right clicking and searching for all instances.  This could streamline the process to see where the fault occurred since the async message block would be in the location of the fault itself.

 

I have currently built something like this that is a reentrant VI whose input is a string and a secondary VI that launches the display message VI.  It's a bit of a work around, but I can display a message to the user while my code continues to do whatever it needs to.  

Attention new LV users, NI has transitioned from being able to purchase LV out right to a subscription based model. Just a warning because LV now has a yearly subscription associated with it.
4 Comments
AristosQueue(NI)
Member

If I understand your request correctly, this already exists. Drop the Three-Button Dialog and wire empty strings for two of the buttons. 

If that isn’t your goal, you may need to supply pictures showing your goal. I wasn’t entirely following your text. 

Reminder to all: I no longer work for NI. I can’t fix whatever it is any more. 🙂

Matt_AM
Member

I'll try to explain better with my PS 2-0 Class.  The basic idea is that I tried to create an abstract factory pattern OO design where the "top level class" (PS 2-0) implements the functionality but doesn't perform any of the legwork, that's the concrete child class's job.  However, some functionality, such as OVP, is not common amongst all power supplies I have. I want to have the PS 2-0 to have that functionality but I also want to let the user known if they selected a PS without OVP that the PS doesn't have OVP but continue with the test.  Typically the tests I run that I'd run that need OVP would specifically have OVP and if I was bench testing my code vs running it on a stand, I'd be there to manually turn off the PS if things went wrong.  So I don't really care in this case that the simple PS I am bench top testing with doesn't have OVP because I know the actual test PS will have OVP.

 

Below is a few images of my code to show what I am talking about.  Here is a simple init the PS 2-0 class, update OVP, then close the class.

Matt_AM_0-1667227446513.png

This is what the Update OVP looks like when I go to open it and the various implementations are shown.

Matt_AM_1-1667227520727.png

Matt_AM_2-1667227548410.png

Here is what the message VI looks like

Matt_AM_3-1667227604298.png

 

This lets my PS 2-0 class send a message to the FP that can be cleared by pressing the okay button but will also let my user know that OVP doesn't exist for this PS type while also letting the main code continue.  So going back to the original code, if I selected a PS that doesn't have OVP, the PS will be initialized, then the popup would let the user know that the PS doesn't have OVP then the PS 2-0 would close.  Even thought the code would finish, there would still be the popup there to let the user know what happened and once they press okay, the window would close.  

 

Digressing to my suggestion of an async popup that still allows code to execute, my solution to display a popup is harder to trace.  I cant right click my popup message and search for all instances for the popup message.  I have to know that the popup message is called by the PS 2-0 class's abstract VI's and then I need to add in additional code to make sure I know what PS and what function caused the problem to send to the popup VI.

 

I hope this flushed out what I am trying to suggest.

Attention new LV users, NI has transitioned from being able to purchase LV out right to a subscription based model. Just a warning because LV now has a yearly subscription associated with it.
wiebe@CARYA
Knight of NI

Of course, it doesn't need to be that much code:

wiebeCARYA_0-1667311958088.png

 

drjdpowell
Trusted Enthusiast

Just a note, but I have Asynchronous Dialogs in Messenger Library.  They are widely useful for more than just displaying a message, such as letting the User enter data without blocking the program.  I have long thought that LabVIEW is missing these kinds of features.