Customer who has used CVI for years and likes it was looking a Mstudio for the reason that a lot of his new engineers can't or don't do the regular C programming. He likes Mstudio as an idea but, with the extra cost of adding MS Visual Studio and dealing with a they support/We support issues of having two SW pkg from 2 different companies gives him pause about purchasing. He stated he likes CVI because if there is an issue (even if rare) he know that NI will help to figure it out. I let him know I'd provide the feedback.
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.
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.)
I have had severe problems in development, due to a high synergy between my lack of attention and CVI behavior in search/replace dialogs.
I am talking about the fact that Find/Replace parameters [namely search directories] are stored at REGISTRY level, so that they remain the same across different workspaces.
Having to work with different version of the same software product, I have found myself looking into the wrong sources, or even doing mass updates, due to the fact that different projects have identically named sources and includes, just in different directory trees, and rapidly switching from one workspace
to the next I didn't "mind the step"
My suggestion, thus, is to store find/replace parameters at workspace or project level, so as to avoid the aforementioned inconvenience
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...
When designing a UI it is sometimes necessary to have text composed of indices and superscripts, e.g. R^2, chi^2, ...
Right now this can be accomplished only by using several texts in different sizes and by manually aligning these text fragments. This is quite tedious
Hence I would suggest permitting simple control sequences to automatically have text parts in superscript, subscript, italics and bold within the very same text message (possibly similar to HTML)
Following this idea already implemented, it could be good to add up/down keys to rows and columns selectors.
At present, if the table is in hot or normal mode you can click on a cell in the table preview in the Quick Edit window to select the corresponding row/column: going to editing them is made easy this way. However, if the table is in indicator mode you cannot click on the cella to select row and column. The same applies if you want to reach a column/row out of visible area of the table: the only solution to that is to double click on the column or row selector and type in the number you want. Not easy nor fast, and prone to errors. Much better to click on a button and increment / decrement the active column index
I'm thinking to something like that:
In earlier versions of CVI source files needing compilation were marked in a different color, unfortunately this feature has been removed in CVI2013. The suggestion is to re-introduce this feature...
Changing an include file immediately shows affected source files
It's always clear how time-consuming it is pushing the RUN button, i.e. if there are files *and how many) to be compiled first
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 , it would be a nice feature for CVI (and LabView?), too.
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.
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.
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
Please conisider supporting multi-touch screen gestures in a similar manner to the mouse events. Windows 7 Mulittouch capabilities are a good place to start. http://msdn.microsoft.com/en-us/magazine/ee336016.
The GUI of the future will most certainly be touch screens, and users expect to be able to use gestures such as pinch, fling, spread, rotate, etc.
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.
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.
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
If the label area is fixed size (i.e. option "Size to text" disabled) and is higher than the font height, it would be useful to have an attribute to set the text vertical alignment:
Now the text can be justified only horizontally (left justified, centered, right justified)
My CVI application started to generate linker errors immediately after I upgraded from CVI 2012 to CVI 2013. A number of other people have reported exactly the same problem, with the linker unable to resolve symbols found in IMAQdx or nivision.
This means that the final release of the new version of CVI cannot have been tested when using the image acquisition or image processing add-ons.
I suggest that, in future, new versions of all tools are subjected to automatic regression tests against the examples distributed by National Instruments before release. Because it obviously doesn't happen now.
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.
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.