VIs disappear from windows taskbar when executing

[billko]

A typical case as you describe is a dialog box.  As far as I know, a dialog box doesn't show up on the task bar.  You have to select the parent on the task bar instead.

So it is reasonable to assume that when the [x] is disabled, Windows treats it as a dialog box.

Ooops nvm.  It would help if I read the original post correctly.

[JÞB]

Carlos,  I appologize for anything I wrote that annoyed you, it was not my intent.

And, thank you for explaining the workflow you are using where the windows behavior becomes problematic!

---

@carlos_camargo wrote:

---

@Case_in_Point wrote:

It really comes down to an assumption on Windows of what kind of windows (little 'w') can't be minimized and what kind of behavior they get. If your window can't be minimized, it's a fair assumption that your user won't need to find it in the task bar. After all, it's still going to be up on the screen. I'm guessing, if you aren't letting users minimize, you probably also aren't letting them resize, so when does it need to be manipulated from the task bar?

Cason

Applications Engr., NI

---

It needs to be manipulated from the taskbar because other windows can come up and cover it.  I might be running this one and editing others, I might have five or six other windows each operating their own instrument all at the same time.  It might not be minimized per-se but still can disappear from view due to actions of other applications.  I might open an MS Word and Excel window, or ten and now how do I find that control for my power meter?  Given that context, it's not that weird to think that a window that doesn't get minimized would still need to be found through the taskbar right?

---

---

So, Let me share with you something about how I avoid this exact bit of frustration (I have even published an internal memoradum on improving the process. (Check out this thread)  I've even managed to get a few forum "Solutions" based on the advice repeated entirely here: 

Champion Tip

The Problem with Modal Dialog Boxes Avoiding the “Three-Finger-Salute”

The Problem:

Let’s be honest, we’ve all done it.  You are debugging your project and create a sandbox vi to explore why you are getting that unexpected result run the sandbox and “POOF” that modal vi that you had open pops to the front and LabVIEW becomes unresponsive.  We need to press Ctrl+Alt+Delete, bring up the Windows Task Manager, and kill LabVIEW (losing all our changes in the process!)

The Reason:

Your vi is saved with the “Best Practice” Windows appearance settings.

Figure 1 Modal Appearance Settings[ NOTE: Figures in source .docx not shown in this copy]

Every Windows application developer will tell you that the desired operation of your modal dialog is that it should not be closable by the red x and block all access to the rest of your application when it is active.  You DID have a reason to create that Dialog Pane in the first place!  Your code is in an unexpected state and needs a human to provide an acknowledgement or make a decision.

Amplifying the problem:

• Legacy Versions of TestStand can load modal dialogs into memory and hide the pane hanging LabVIEW and TestStand.
• Unit Tests for dialog boxes or Modal GUIs cannot be written effectively since you cannot interact with the test framework while the dialog is open (Under Test.)

The Misconception:

This is just one of many examples of LabVIEW “Best Practices” that “Everyone knows about” but, has been obsoleted by improvements made to the LabVIEW development environment.  In this case the practice should have changed between 5.1 and 6.i when VI Server was first made available.   The misconception being that the VI must be saved knowing its Windows Appearance settings.   Really, only two of those setting can cause us a problem; FP.Behavior and FP.Closable and, they are both writable while running! [To Carlos' work flow, other FP properties may be addressed in a similar manner to avoid vi's missing from the task bar at edit time in the IDE]

Better Practice:

Use property nodes on your dialog vi’s to set the correct windows behavior only while the vi runs!   So we can save the vi with these settings and still get the desired run-time behavior without having the undesired development environment crashes in LabVIEW or TestStand.

The Code Capture is in LabVIEW 2012 the attached vi is saved back to LabVIEW 8.0. [Edit: the PNG and vi are embedded in the source Word docx, while not attached here, there is a sample snipett in the link above] Notice that we have not only solved our primary problem but, we can also change the “Modal” constant to a control with a default value of Modal and attach it to the connector pane as an optional terminal.   Then we have the option to override the default behavior (HINT: make it “Floating”) for unit testing.

[JÞB]

Thinking it through even more:  An alternate workflow idea popped to mind.

Why are we depending solely on the windows task bar?  A few well placed bookmarks would allow instant navigation to these vi's via the bookmark manager

[JÞB]

And, while I'm at it (suggesting alternates to the Windows Task bar) even if you forgot to add bookmarks, the VI Heirarchy window makes it rather easy to find the vis you are looking for.  And, you certainly should have the project organized well enough to navigate the Project Explorer window.  Each of these: BMM, PE, Hierarchy View, even offer instant access to either the FP or the BD depending on the plat mods of the mouse double click (Ctrl + Double Click for the BD) while the disorganized list in the task bar does not even graphically differentiate the types of files LabVIEW uses.

All in all, my take is firming up to something like - "Why depend on the disorganized task bar list at all?"

[carlos_camargo]

Thanks Jeff·Þ·Bohrer for all the good ideas on how to resolve the problem.  I think they adds to the discussion and a future person with a similar problem might find that you provide exactly the information they were looking for.

The solution I went with was to just check the box to "Allow user to minimize window".  This solves it for me at edit time and for the user at run time, there is a top-level VI that they use to access applications but only to open them. 

I have started using a tree view of my top level VIs which I did to avoid them running when opened, when I just wanted to open them.  I don't make projects unless I need to build for a different platform or executables, in this case I don't so I've not made a project.

P.S. Apologies for lagging in responding, I didn't get a notice of new posts on this question.