LabWindows/CVI Idea Exchange

Community Browser
About LabWindows/CVI Idea Exchange

Do you have a feature idea for how to improve LabWindows/CVI? Submit and vote on ideas now!
  1. Browse by label or search in the LabWindows/CVI Idea Exchange to see if your idea has previously been submitted. If your idea exists, be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click New Idea to submit a product idea. You should submit a separate post for each idea. Watch as the community gives your idea kudos and adds their input.
  3. Give kudos to other ideas that you would like to see implemented!
  4. NI R&D will review ideas that have been submitted and update the status.

Note: the LabWindows/CVI Idea Exchange is not the appropriate forum to submit technical support questions.

The LabWindows/CVI R&D team is committed to reviewing every idea submitted via the LabWindows/CVI Idea Exchange. However, we cannot guarantee the implementation of any LabWindows/CVI Idea Exchange submission.

Top Kudoed Authors
User Kudos Count
1
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

When operating graphs in Labview, it is easy to change the scale of an axis of a graph (at runtime): to change e.g. the maximum value, you select the current maximum value with your mouse, type in the maximum number you want and hit enter. To achieve the same in Labwindows, you have to use a numeric control and a button, which is a bit cumbersome. The same applies for zooming: In Labview, you can click a small button attached to the graph and select the way you want to zoom, and then just use the mouse. In Labwindows, you have to know that zooming is done using the ctrl button, ctrl+space restores the previous setting, etc. It would also be nice to be able to enable autoscale by right-clicking on an axis and having a popup menu which allows to do so (just like in Labview). And if the user changes e.g. the maximum value while autoscale is enabled, it would be nice to automatically disable autoscale (unlike in Labview).

 

So in general, it would be nice to have more comfort in operating graph controls.

 

Thanks.

Summary:

Improve the Breakpoints Window, so that breakpoints can be more easily managed.


Description:

1. Change the Breakpoints Window, from a modal dialog to a dockable window (similar to the Watch Window). Debugging can be more easy this way.

2. Allow breakpoints to be grouped, disabled/enabled and edited in user defined categories. This allows users to easily collectively manage several breakpoints at a time. It also helps the user to logically group breakpoints, depending on various issues issues that he might be working on.

3. Breakpoints could also be sorted from a pop-up menu by filename, line, hit count, etc.

 

Breakpoints Window

If the thread that FileSelectPopup (and similar) is accessed is multithreaded, wacky things happen. The programmer can fix this by creating a new thread that is itself not multithreaded and pass information back to the current threrad. It would be helpful if the current functions were designed to default to create such a thread,  return the value(s), and garbage collect removing the programmer from the loop.

 

In the case of MultiFileSelectPopup, it is not clear to me what would be the best practice given the unknown number of results. I guess one could assume a limit for the number of results that may change as the Windows API does.

 

Other possible solutions can include an added parameter (variable switch) or with a whole new function. I could see the default case as an effective solution for legacy code that is partially refactored for multithreaded performance.

When building a project consisting of many files it would be much more convenient if the Build Output would jump to the line with the first file showing an error (or, if no error occurred, to the first warning).

 

Right now, if there is a build error I have to scroll through the (possibly long) list of files to see which file produced the error; only then I can click on the error message to have the IDE highlight the problematic line.

 

Thanks

As suggested by Daniel (D-Cubed) an improved version of GetCVIVersion is needed in order to determine the patch level programmatically. Right now, no simple approach exists for an executable to determine if the CVIRTE is a patched version or not. For example, GetCVIVersion returns 1300 both for the patched and the unpatched 2013 release.

 

Thanks.

Hello,

 

working with larger UIs may result in scrollbars showing up in the UI editor. Hence it would be nice if hitting the 'PageUp' or 'PageDown' keys would scroll the page up or down, respectively. Also 'Home', 'End' and the four cursor keys should be supported, similar to their functionality in the text editor. 

 

Thanks!

Hello,

 

imho the nice tool tips feature provided by the Programmer's Toolbox leads a miserable existence, because it is extra effort integrating it into a GUI.

 

I would love to see the tool tips integrated into the IDE, that is, when editing a control in the GUI editor, I would like to be able to also set the tool tips text and if it is initially enabled, just like it is possible to enter a control label text. This would include moving the tool tips from the Toolbox to the regular user interface library.

 

Many Thanks!

 

 

I would consider it useful if the Build Output would state the total number of errors in a file - right now it says: 1 file with errors, but especially if you start with many errors I find it helpful to see if a change in code reduces the error count.

 

To my knowledge earlier versions of CVI provided this information, which disappeared with clang integration.

 

Related posts are here and here

I would like to have the possibility to store the uir-file not as a tui-file (old-fashioned ini file), instead as a xml file.

Even after using CVI for many years I still find the DirSelectPopup confusing, because it provides a file selector, displays files, and even allows to select files...

 

I would prefer an improved/modified function such that the DirSelectPopup only shows directories, does not provide a file selector, etc.... This should make it much more obvious that one is selecting a directory, not a file...

 

Thanks!

Similiar to LabVIEW, I would like to have a "save as" option to store all files within the prj-file to a new location (maybe also for store a cws, res all mentioned prj-files).

Would make it easier to handle over a CVI-project.

  • Usability

Currently, there is no way to access the historical data on a stripchart.  The only way to manage this data is to maintain a separate buffer and update it whenever you add data to the strip chart, which is inefficient and tedious. Accessing data is possible for graph controls using the data attribute:

 

GetPlotAttribute (panel, PANEL_GRAPH, plotHandle, ATTR_PLOT_XDATA, &data);

 Something similar should be implemented for the strip chart, either as an attribute in the getTraceAttribute function, or as a standalone function (getTraceData, etc.)

If you have, say, three controls called MAX_1, MAX_2, MAX_3 arranged vertically. If I select them all, copy and paste, the new controls appear as MAX_4, MAX_5 and MAX_6 but in the wrong order to what you would expect.

i.e.

MAX_1

MAX_2

MAX_3

 

becomes

 

MAX_1

MAX_2

MAX_3

MAX_6

MAX_5

MAX_4 

 

A similar issue occurs with assigning a group of controls to a control array, they always seem to be in the wrong order, usually reversed.

Hi,

 

Currently, when a CVI application is deployed on a PC with a DPI setting different than the development machine, the application will generally not look like how the programmer intended as the fonts get resized while the other UI elements do not, leading to overlapping text, awkwardly resized controls, etc.  One way that DPI scaling could be implemented in CVI would be to use the same functionality as the 'Scale Contents on Resize' option for panels, where internally CVI could resize the panel and use this scaling to rescale all the UI elements (including fonts) on the panel to the appropiate size per the Windows DPI setting.  This would make the panel look a lot closer to what the programmer intended and would generally make most applications usable with different DPI settings without any additional work from the programmer.  Per my other suggestion, I would request that the programmer has the capability of disabling this functionality so they can handle DPI scaling themselves should they wish to do so.

 

Thanks.

It has been suggested much earlier here, but obviously passed out of mind:

 

When using 'Go to Definition' (CTrl+I) while in release configuration, CVI tells that no source code information was found for the identifier '...', because 'Browse information is not available in the Release configuration'... (still true for CVI2010)

 

This can and should be improved!

 

And it might be a good opportunity to also add the reverse process, 'Goto Declaration', suggested here

I made this suggestion some time ago - unfortunately I had combined it with another, related idea. The other idea was implemented so now the complete issue is dead, sorry, completed. Smiley Surprised

 

This suggestion is meant to revive the unfulfilled request of two new attributes, allowing to dim and hide a specified entry in a ring control. This would be convenient as it avoids to programmatically rebuild the control.

 

Thanks!

 

 

This would make it a bit easier to edit an old project without the issue of upgraded UIRs because it might get loaded by the wrong CVI version and one edits and accidentally saves it before noticing.

 

Visual Studio installs a helper EXE which launches the right Studio for any SLN.

 

If MS didn't patent this Smiley Wink, it would be a nice feature for CVI (and LabView?), too.

  • Usability

Most user settings are kept in either the project or the workspace file. Unfortunately, this is not true for building a function tree (Options/Generate Function Tree). Starting CVI the previous entries are lost. Actually this is an old issue but may be not too old to be improved... Smiley Wink

 

So I suggest to save the information about Instrument name, Function prefix, Default qualifier, and Output function tree in the appropriate configuration file (prj or cws)

 

Thanks Smiley Wink

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

                 

 

Hello,

 

building upon my earlier (but difficult to implement) suggestion and the forum discussion on event data here I can provide a hopefully improved suggestion.

 

The issues addressed by this idea:

  • receiving an EVENT_DATA_CHANGED event for a numeric control does not mean that the numeric value has changed
  • receiving an EVENT_DATA_CHANGED event for a numeric control does not provide information if the value has been increased or decreased
  • receiving an EVENT_DATA_CHANGED event for a numeric control does not provide information if the 'up' or 'down' arrow button has been pressed (which is not necessarily the same as the second issue)

Idea: Provide eventData1 and eventData2 information.

 

For example, eventData1 could tell about the numeric value:

  • eventData1 = -1: numeric value has been decreased
  • eventData1 = 0: numeric value is unchanged
  • eventData1 = 1: numeric value has been increased

eventData2 could tell about the increment/decrement arrow, e.g.:

  • eventData2 = -1: decrement arrow has been pressed by mouse
  • eventData2 = -2: decrement arrow has been pressed on keyboard
  • eventData2= 1: increment arrow has been pressed by mouse
  • eventData2= 2: increment arrow has been pressed on keyboard

Since so far no eventdata are provided this suggestion should not break backward compatibility.