LabWindows/CVI Idea Exchange

A useful CVI GUI tool would be the addition of sideways tree-style tab control.  I am surprised to see no mention of it in the forums.  Is there already some solution for it, or perhaps some Active-X that can do it?    Nevertheless, it would greatly modernize the GUI arsenal.

Hello,

building on this suggestion I'd like to see a more comfortable panel of the UI editor for editing label/value pairs, see below:

Suggested changes:

1. Add the possibility to dim / hide the selected entry
2. Add the possibility to insert separators in the GUI editor, not only programmatically
    
   Thanks!

Adding to the many pending feature suggestions for tooltips (here, here, here, here and here) I'd like to suggest one more: please make tooltips more beautiful, i.e., drawn with rounded rectangles and with a shadow, see below.

Hello,

watch expressions support the possibility to monitor changes of variables by placing the variable in the watch window. Unfortunately, at present it seems impossible to put a 2 D variable in the watch window, e.g., x_data [  2  ] [  3  ].

The new idea is to allow this

Thanks!

Starting CVI the IDE uses cpu resources even if sleeping, i.e. doing nothing except waiting for user input. It seems that the IDE is also using the scheme of SetSleepPolicy...

Today most other software does better and I would like to see an improved behavior: use cpu (and thus energy...) only if something actually needs to be done

From the CVI Help:

Some Interface to Win32 Application Programmatic Interface (API) functions have the same name as some LabWindows/CVI functions, causing a naming conflict. You must include the Interface to Win32 API include files before the LabWindows/CVI include files. LabWindows/CVI automatically resolves the conflict by using the LabWindows/CVI implementation of the function. To use the Win32 API implementation of the function instead, define the SDK_CONFLICT_PRIORITY macro in the Compiler Defines section of the Build Options dialog box.

If you enable the SDK_CONFLICT_PRIORITY macro, you cannot use the following LabWindows/CVI functions and should use the Win32 API implementation instead.

Formatting and I/O Library

• CloseFile

• OpenFile

• ReadFile

• SetCommitMode

• WriteFile

Utility Library

• Beep

• CopyFile

• DeleteFile

• GetFileSize

• GetFileTime

• GetSystemTime

• SetFileTime

• SetSystemTime

• inp

• inpd

• inpw

• outp

• outpd

• outpw

Based on my experience these name conflicts have no advantages, and create a lot of problems: usually I use the CVI implementation, but it happens that after some time I need the Win32 API implementation of one of these functions (GetSystemTime(), for example).

In this situation I must heavily modify my code, changing the calls to all the above functions.

I don't like these naming conflicts at all.

I suggest that a "_CVI" prefix (or something like that) is added to the CVI implementation: an old project will recompile perfectly simply adding this prefix to the calls, without modifications to variables, structures, ...

As of CVI2013 data tooltips and variable view do some kind of automatic rounding but based on 15 digits only... This prevents tracking numeric / rounding issues. Unfortunately, no possibility exists to show the full precision of doubles... Phrased more drastically one you cannot use CVI to debug numeric issues...

So I suggest to urgently add

• as a minimum version the possibility to show true numbers, not rounded numbers, allowing true debugging
• as a more general version the possibility to adjust the precision of displayed numeric values

When compiling projects with several files the build output window sometimes is flooded with warning and error messages. Typically I focus on one file at a time and then have to scroll through this long list searching for the file of interest. In such a situation I would consider it useful having an additional menu entry in the right click menu (shown below) such as 'Collapse All', reducing the many lines in the build output window to one line per file, greatly simplifying the search for a specific file.

Thanks!

As can be seen here, "Save changes" items in Environment options are global to the CVI IDE.

I suggest these options are made project-specific instead. The rationale behind this suggestion is simple: suppose I am developing project A and I enable autosave modifications before compiling and running the project; at the same time I may need to look at the code for project B already deployed to customers, and I want to prevent modifications to the code without notice. At present, while I am testing the application A I set these options to "Always"; if next I come and see the code for project B, I may accidentally make (and save!) modifications that change the code of the deployed app without notice 

If these options were per-project I would be granted I am not making mistakes.