I have an application where the "second monitor" of the Windows computer is actually a projector, used in running a test.  I display test patterns on this monitor, but the User can't see them.  The problem I am having is ensuring that all dialog boxes, including error dialogs, show up on the primary screen always.  But, intermittently, they start to show up on the projector.   I cannot seem to discover how Windows/LabVIEW decides which monitor to show dialogs on.   Does anyone know?  

View File UI Tools
UI Tools v1.4.0
Copyright © 2009-2016, François Normandin
All rights reserved.
Author:François Normandin
Contact Info: Contact via PM on www.lavag.org
LabVIEW Versions:
Created and tested with LabVIEW 2012
Dependencies:
OpenG Application Control Library >= 4.1.0.7
OpenG Array Library >= 4.1.1.14
OpenG File Library >= 4.0.1.22
OpenG LabVIEW Data Library >= 4.2.0.21
OpenG String Library >= 4.1.0.12
LAVA Palette >= 1.0.0.1
Description:
This package contains tools for designing user interfaces.
A first palette helps create special effects using transparency of front panel. Using them allows to quickly create fade-ins or outs using linear or exponential variation of the intensity. A second palette contains VIs to calculate the position of GObjects for many purposes like alignment, snap, mouse follow, etc. A third palette contains VIs to create dialog boxes based on class instances. "Simple Error Dialog" and "Simple Selection List" are featured with or without backrground blackening effect. A fourth palette includes some VIs to move objects programmatically on the front panel, using a basic deceleration algorithm to provide an impression of a smooth movement. The packaged VIs are all namespaced using a suffix “__lava_lib_ui_tools” which should not conflict with any of your own code.
Includes:
Front Panel Transparency (Fade In & Fade Out) Utilities (Alignment, Snap) Dialog (OOP based, extensible) Engine (Beta) for object movement Instructions:
This package is distributed on the LabVIEW Tools Network (version 1.3) and updates are on LAVA (1.4). It can be installed directly in the addon folder of any LabVIEW version from 2012 to now. The addon installs automatically under the LAVA palette of the addon submenu.
License:
Distributed under the BSD license.
Support:
If you have any problems with this code or want to suggest features, please go to www.lavag.org and navigate to the discussion page.
 
Submitter Francois Normandin Submitted 09/21/2009 Category LabVIEW Tools Network Certified LabVIEW Version  

UI Tools v1.4.0
Copyright © 2009-2016, François Normandin
All rights reserved.
Author:François Normandin
Contact Info: Contact via PM on www.lavag.org
LabVIEW Versions:
Created and tested with LabVIEW 2012
Dependencies:
OpenG Application Control Library >= 4.1.0.7
OpenG Array Library >= 4.1.1.14
OpenG File Library >= 4.0.1.22
OpenG LabVIEW Data Library >= 4.2.0.21
OpenG String Library >= 4.1.0.12
LAVA Palette >= 1.0.0.1
Description:
This package contains tools for designing user interfaces.
A first palette helps create special effects using transparency of front panel. Using them allows to quickly create fade-ins or outs using linear or exponential variation of the intensity. A second palette contains VIs to calculate the position of GObjects for many purposes like alignment, snap, mouse follow, etc. A third palette contains VIs to create dialog boxes based on class instances. "Simple Error Dialog" and "Simple Selection List" are featured with or without backrground blackening effect. A fourth palette includes some VIs to move objects programmatically on the front panel, using a basic deceleration algorithm to provide an impression of a smooth movement. The packaged VIs are all namespaced using a suffix “__lava_lib_ui_tools” which should not conflict with any of your own code.
Includes:
Front Panel Transparency (Fade In & Fade Out) Utilities (Alignment, Snap) Dialog (OOP based, extensible) Engine (Beta) for object movement Instructions:
This package is distributed on the LabVIEW Tools Network (version 1.3) and updates are on LAVA (1.4). It can be installed directly in the addon folder of any LabVIEW version from 2012 to now. The addon installs automatically under the LAVA palette of the addon submenu.
License:
Distributed under the BSD license.
Support:
If you have any problems with this code or want to suggest features, please go to www.lavag.org and navigate to the discussion page.
 

Hi, I'm writing a LabVIEW application using the Actor Framework. This is the first time that I have used the framework and I need some advice regarding application architecture. My apologies if this is a basic question!

 

How is a settings dialog box best implemented? In the past in non-Actor Framework applications I have loaded the configuration from a functional global variable, displayed the settings dialog, then written the updated settings back to the functional global. I'm not sure this would work correctly (or optimally) within the context of the Actor Framework, though. 

 

My application uses the template generated by Create Project -> Actor Framework. The top-level Actor manages the user interface. Two child Actors control separate pieces of hardware. The top-level actor must read a saved configuration from an INI file when the application starts, and save the final configuration back to the INI file on exit.

 

Instinctively I think it would be best for each child actor to maintain its own settings, as a cluster in its class private data. Ideally I don't want to have to keep a separate instance of the two clusters of settings in the top-level Actor's private data in order to populate a settings dialog; this duplication seems unnecessary.

 

The only way I can think of to make this work is as follows.

 

At application start

1. Top-level Actor reads settings from INI file.

2. Send messages to both child actors with the new settings, and tell them to apply those settings to their private data.

3. Each child Actor should respond to acknowledge that the private data has been updated.

 

To update the settings using a dialog box

1. Send a message from the top-level Actor to each child Actor to ask them to send their settings to the top-level Actor.

2. Wait for both child Actors to reply.

3. Display the dialog box.

4. If the user clicked 'Ok' and not 'Cancel', send messages to both actors with the new settings, and tell them to apply those settings to their private data.

5. Each child Actor should respond to acknowledge that the private data has been updated.

 

On exit

1. Send a message from the top-level Actor to each child Actor to ask them to send their settings to the top-level Actor.

2. Wait for both child Actors to reply.

3. The top-level Actor writes the settings to the INI file.

 

This doesn't seem like a sensible approach, though. Waiting for message replies sounds like the wrong thing to do. I wouldn't know where in the block diagram to implement this scheme, either.

 

Can anyone offer me any advice? There must be a fairly standard way of doing this that I'm missing!

 

Thanks in advance,

Chris

 

---

Dr. Chris Empson

Robot Screening and Instrumentation Specialist

School of Chemistry

University of Leeds

UK

 

CLD

Hello forum LAVA-ites,
 
I am attempting to write a Tools Menu item to slot into the IDE. The intent of this "Tools" VI is that it determines the application instance that launched it and dynamically run a VI in that application instance so that the launched VI can access VIs in that instance. This is basically a custom Unit Testing tool that looks for particular VIs in the project that houses the application instance.
 
I was attempting to use the App.MenuLaunchApp property in this "Tools" VI so that I could wire up an Open VI Reference node with the right application instance and the name of the VI to run dynamic VI to run. I added an extra indicator on the launched VI to show what application context it is running in.
 
If I have a VI open from a Project and then launch the "Tools" VI from the Tools menu, then the dynamically run VI indicator shows "My Computer" (referring to the project housing the application instance). However - if I launch the "Tools" VI from the Tools Menu while Project Explorer is showing then the dynamic VI launches in the NI.LV.Dialog irrespectively (the indicator on the front panel of this VI shows this).
 
Is this expected behaviour? Is there a way around this so that the dynamic VI gets loaded into the right application instance even if launched from Project Explorer?
 
Thanks in advance.