LabVIEW Bug or Idea Exchange Feature?

[Matthew_Kelton]

So, I do not know if NI would consider this a bug or a feature request.

If you create a VI for Data Member access, when you go to save the VI(s), the starting diretcory is always the Desktop, and not some relationship to the location of the class.  For other new VIs (from Static or Dynamic Dispatch, or just plain VI), the starting directory for saving is the directory in which the class resides.  I think it should be consistent with how the other VIs save feature behave and find the behavior extremely annoying, especially when I need to create a lot of Data Member VIs at once.

This is LabVIEW 2011 (although the isue has been here since LVOOP was introduced, I believe) and Win 7 (although I know it occurs on WinXP as well).

[Matthew_Kelton]

I should add that this also occurs under some circumstances in libraries as well.

[falkpl]

Funny I was discussing this with a coworker today (same complaint).  I found if I drag the Vi back into the library before saving it will start in the correct library, but I dont understand the logic of starting in the desktop.

[tst]

I have never seen it starting in the desktop. For me it always starts in the folder of the class (both XP and 7, and as far as I remembered did this in 8.6 as well) so I would say it's a bug.

Maybe it's related to user permissions (e.g. maybe the function LV uses to set the path can't do it in lower permissions and outputs the desktop as the default value)?

[Matthew_Kelton]

I have been able to find a situation where this occurs repeatably.  Perhaps this is the source of the problem.

In a lvlib, if you create a virtual folder, and create a VI by right-clicking on the folder and choosing new VI, LabVIEW will start in the Desktop.  If you do new VI from the lvlib parent, LabVIEW uses the directory where the lvlib resides.

I would think that it should default to the directory of the lvlib, class, etc. instead of the desktop.