LabVIEW Idea Exchange

Currently, to allow a user to select a relative path within a Path control, you must either:

1. Easy (but glitchy) method:

 - Catch the value change event on the Path control;

 - Compare the NewVal with your base path with "Compare Two Paths.vi";

 - In case the path is relative to your base path, rewrite the relative path to the control using a local variable;

 -> This results in a visual glitch because the value is updated twice.

2. Recommended (but complicated and not very clean) method:

 - Take a first Path control, move the "path box" out of view, but keep its browse button visible;

 - Put a secondary Path control next to it, with its own browse button invisible;

 - Similar to method 1: catch event on first path, update secondary path;

-> No visual glitch, but difficult to adapt to paths inside arrays, clusters and combinations of both.

For both methods, additional logic may be needed in case the user is typing in the path box directly.

So the idea would be to add a "Base Path" property to the Path control, so that when the user clicks the browse button and selects a path that is relative to that base path, the control would get the relative path value instead of the absolute one.

In case the selected path is not relative to that base path, the control would still have the normal behaviour and get the absolute path value.

By default, this property would be set to "Not A Path" (or empty path) to keep the current behaviour.

Also, it would be the developer's duty to correctly treat relative path values and inform the user to what base path it is relative to.

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.  

This might be a bug report; it depends on whether todays behavior is intended or not(?).

Anyway: if you have properly defined the destination of a file in your application build e.g. on Source File Settings, but then later learn that the file was not actually on the list of source files - adding it to source files will automatically change the destination(!). I suggest it should check whether the user has already defined a valid destination for it and if so keep it.

Here is a demo of the issue: