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.
Several CVI functions exist that permit to add / install functions in the code. At present, we need to manually create the function prototype, and the fastest way I found is this one: open the function panel for e.g. InstallPanelCallback function, select Event Function parameter, right-click the field or press F1 to show the help, select the function prototype dragging with the mouse, Ctrl-C to copy it, close the function panel and paste the prototype in the code.
It would be *very* handy if a way existed to speed up the process: a "Generate Prototype" item could be added to Code menu that takes the function name set by the user in Event Fuction field and generates the appropriate function prototype in the source code.
There is a huge set of functions that could benefit with this addition, following is an initial list but I am sure I'm missing some more functions:
In the User Interface Library:
In the Utility Library:
In RS232 Library:
In VISA library:
In DAQMx Library:
In TCP Library:
In Network Variable Library:
In the ActiveX Library:
In the Asynchronous Timer instrument driver:
In the Programmer's Toobox:
And don't forget all sorting functions that require a comparison function to operate:
This X just closes out of the tab that is on top.
Pretty much every other program with tabs has the X on the tab you’re closing out of. The current placement makes me hesitate every time, because it feels like you’re X-ing out of the entire code-viewing pane, not just the single file you want to close.
It’s also not consistent with the rest of the environment.
For example, in the pane on the bottom in the screenshot above, “Threads” and “Wa tch” look like two tabs, but clicking the X in that pane causes the entire pane to disappear rather than just closing the tab that is on top.
For some specific projects it's required that the code is compliant to MISRA C guidelines (see here)
A feature to check the compliance of the C code with MISRA C guidelines would be useful.
The best option would be to have the possibility to select a subset of the rules or to disable some of them.
NI is not a C/C++ Editor-Debugger company. And, it will never be able to invest the man power needed to get there. NIs strengths are its Instrument UIs, its libraries, and it's visual application UI pieces. The LabWindows/CVI tool looks and feels like tools from the mid 90's (ie. like an old Borland C editor, but even less featured). It lacks the toolset found in VisualStudios, NetBeans, and Eclipse. And, it will always be behind.
The Verigy93k tester was like this several years ago. They wrote their own C/C++ editor, and it was at a mid 80's level. When a team was asked to rewrite the UI and bring it up to date, they made a novel choice (they recognized that they were not a UI platform / editor company), and they moved their product under Eclipse. Teradyne Flex did something similar a year or two later moving under Excel and Visual Studio. The thing is this, both companies realized that they could make more money focusing on their real strength. They added libraries and apis to work in the platforms framework, and changed/adapted the platform framework to work for them. ie. Teradynes Flex test tool does not say "Excel/Visual Studio", it says it is a Teradyne product based on MS Excel and VS. And, they have adapted the platform to their needs adding on the extra Windows/UIs/... to meet their needs. Same with the Verigy 93K.
In Teradynes case, they went back to the drawing board. So, we will ignore this (even with their success). In Verigys case, all their existing APIs worked in the new platform, and the user didn't need to change anything when they upgraded. But, suddenly the Editor and Debugger were up to date, with latest greatest features. It was a huge change overnight.
LabWindows really should make a shift to Eclipse. Keep your old legacy stuff at first, but working under Eclipse. Add in "Views" and "Tools" to supplement what Eclipse doesn't give you for free. And, remove unwanted or confusing plugins from the eclipse base. (This is what advantest did.) Leave in features that make Eclipse great, like error view, and the ability to have several "perspectives". And really focus the man power into making a product that will blow the others out of the water. NI has what it takes to make great Instrument editing/debugging windows in Eclipse. But, NI doesn't have the 1,000's of people and millions of man hours required to make an Editor/Debugger that will compare to the Eclipses/VisualStudios of the world. As a business they should focus on what will make them a differentiator, and reuse what is accepted and common.
Anyway. My 2 cents on how you could really improve LabWindows in a few short months. (Note: Verigy spent all of 9 months and 9 engineers on their C/C++ integration into eclipse... I know... I was there at the time.) If you took the LabWindows team, and a year or two... Imagine how much better of a job you could do.
As discussed here, distributing the code of
int main ( int argc, char *argv  )
printf ( "%s", "Hello world" );
generated in CVI2013 results in a distribution kit of 74 MB minimum... Using the NI default settings results in 219 MB...
Yes, I do have TB drives, but I dislike bloated software.
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.
At present CVI is missing a serious report printing facility that permits to create flexible, professional and good looking reports.
A quick search in CVI forum shows that periodically somebody posts questions about reporting but available instruments at the moment are not satisfactory in my experience.
As far as I can tell, a good reporting instrument:
Add an attribute for LabWindows/CVI panels for setting transparency.
Currently, in order to achieve this behaviour users are forced to workaround this using Windows API.
Having an attribute for this purpose would allow users to benefit from this functionality more easily and would make LabWindows/CVI programs more cleaner.
Related forum discussion: http://forums.ni.com/t5/LabWindows-CVI/Transparent
The CVI runtime engine calls the Windows API function SetProcessDPIAware() that tells Windows that the application is DPI aware in Windows Vista and later. This seems to be forced upon all applications built with CVI, whether they are actually DPI aware or not. Most applications built in CVI using the default tools are not going to be DPI aware out of the box, and setting Windows to another DPI setting than what the programmer used to create the UI will cause many graphical glitches and possibly make the application unusable. The purpose of this request is to suggest to NI that the CVI Runtime Engine not call SetProcessDPIAware() so that the programmer can handle (or not handle) DPI scaling as they see fit. If the programmer does nothing, the application will then, by default, be scaled using Windows DPI Virtualization. This is not optimal, but it would leave the application usable and looking like how the programmer intended.
This is per this discussion here:
At present, autoscaling works with respect to the full provided data set, i.e. if all data are shown on the graph.
If say the X axis is set to manual scaling such that only a subset of all data is plotted, autoscaling of the Y axis still considers all data even if they are not shown, see the discussion here.
Hence it is suggested to provide an additional auto scaling mode which considers only the data actually visible on the graph, say VAL_AUTOSCALE_VISIBLE_DATA, complementing the current VAL_AUTOSCALE which actually is a VAL_AUTOSCALE_ALL_DATA
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...
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)
I want to be able to do the following:
If you haven’t written any code in the callback already, you can just change the default events and re-generate (replace) the control callback.
However, if you have already written code for one event case, the only way I can find to add an event case is to do it manually. I go to Code>>Preferences>>Default Events or use the Operate tool to look for the constant name of the event that I am interested in, then I go back to my code and manually type out “case EVENT_CONSTANT_NAME: break;” with the name of the event and hope I remember it correctly and spell it right.
CVI is all about minimizing user errors and reducing development time by, you know, not making you type things out yourself, so I think this functionality would be a useful addition.
because I had installed CVI2010 on a brand new Windows 7 machine, I was curios to find out about all the service processes running on the system.
It seems that there are quite a few NI services that start after log-on. Some of them seem superfluous, such as the Lookout Citadel service (no LabVIEW, no Lookout installed), but due to the lack of any information I did not bother trying to stop them
1) NI should critically review the services and only start the services that are absolutely needed.
2) Services that are optional might be selected by a checkbox during installation or from the Options / Environment setting
3) NI should provide some documentation / explanation of each service and why it is needed.
there has been the valuable suggestion of a "Picture and Text" button allowing more modern buttons.
For all those focusing on programming instead of UI design it would be also nice if CVI could provide more default buttons ready to use as some examples shown in the image below (taken from the NI community).
As they seem to be already available in LabVIEW it shouldn't be much effort for NI to adapt them to CVI... - hopefully
Display more struct member information during source editing and during debug.
While editing source code, CVI only displays the struct members, but no information regarding the type of the member (or declaration information, line file and line).
Add a tooltip to the right of the pop-up displaying the struct members in the source editor to display this information. Similar to this picture:
Also add support for displaying nested structs and even display the member values while debugging, in form of a tree, when execution is suspended (CVI currently only displays the memory address of that struct variable).
Right now it is possible to set the color, and since CVI 2013 also the line style, of all grid lines collectively.
I would like to distinguish between major grid lines and minor grid lines, e.g., draw major grid lines with dashed lines / light grey, and minor grid lines with dotted lines / dark grey.
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:
Idea: Provide eventData1 and eventData2 information.
For example, eventData1 could tell about the numeric value:
eventData2 could tell about the increment/decrement arrow, e.g.:
Since so far no eventdata are provided this suggestion should not break backward compatibility.
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.