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.
In CVI 2013 the array display has changed (for the worse, in my opinion).
There are two minor inconveniences and one acute shortage I would like to see improved (hopefully prior to CVI2020 )
First, the right click context menu: If I want to see values of a numerical array, it offers a 'Graphical Array View' but no 'Array View', so one first has to chose 'View Variable Value' and then 'Array Display' - maybe one could save one step and already provide the 'Array Display' in the first case...?
Second, the new Array View table still is very slow, not extremely slow as prior to SP1 but still very slow...
Most importantly, at present it is impossible to debug large arrays, large meaning arrays with more than 10000 elements. The current implementation requires to select a slice of data - but this makes it impossible to check or compare say array indices 5, 10005, and 20005...
Of course I agree that there is no need to simultaneously see more than 10000 data values - but why not have a table with say 100 rows that can be turned over, e.g. displaying either elements 1-100, 101-200, ... this way one could access and inspect all array values...
As a result, starting CVI one first has to locate all the files, where did the include file go...? If you happen to have some more tabs this is a waste of time.
Also, as Roberto mentioned, you can not easily use the short cut keys Ctrl-1 etc. because of the changing assignment.
So, in short, I am asking to improve this behavior and maintain the tab order of CVI workspace files, that is, re-arrange/re-open the tabs in the order they were when CVI was closed.
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.
This issue is that old that we all forgot about it...
But this thread brought it back to my attention and I'd like to suggest two improvements:
Setting the width or the height of a control does not always succeed because there are limitations concerning the minimum and maximum size.
If a function fails it should return a warning. However, calling e.g. status = SetCtrlAttribute ( panel_handle, PANEL_RING, ATTR_WIDTH, 5 ) returns success (0) even though the width of the ring control will be much larger than 5 pixels. For checkboxes, the situation is even worse because checkboxes are drawn right aligned to a transparent rectangular frame. So calling status = SetCtrlAttribute ( panel_handle, PANEL_CHECKBOX, ATTR_WIDTH, 500 ) will result in a transparent drawing rectangle of width of 500 but with the checkbox size remaining at the default size. Since the checkbox is drawn right aligned to this transparent frame the checkbox eventually may disappear from the panel (setting the width to say 10000 will not draw anything).
Complement the documentation, the idea is given below:
Data Type: int
Description: The width of the control body in pixels.
Valid Range: 0 to 32767
Control Type Restrictions: Not valid for controls of type CTRL_VERTICAL_SPLITTER and CTRL_VERTICAL_SPLITTER_LS
For checkboxes, the minimum size is ... pixels, and the maximum size is ... pixels.
For ring controls, the minimum size is ... pixels.
LabWindows/CVI Compatibility: LabWindows/CVI 3.0 and later
Control Types: All
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.
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:
Using CVI I can't find an easy way of moving inside a source code file.
Based on my experience with other C editors, I suggest these 3 little features that I think are really useful:
I have thease features in an open source C/C++ editor (Code::Blocks) I use for other projects, and I think they're really useful to reduce the coding time.
When you have large source files with a lot of functions, with CVI is't difficult to easily see where you are inside the file; moreover it's quite common scrolling the file jumping from a function to another.
Data Tooltip should also display the name of the function, when displaying the value of a function pointer variable.
While debugging a CVI application, when hovering the mouse cursor over a function pointer variable, the Data Tooltip displays the address of that function, referenced by the variable.
It would be very useful in cases when you have multiple function pointer variables referencing several different variables, to have the Data Tooltip not only display the address of those functions, but the name of the functions as well.
(Coming from this forum discussion)
If you double click on a UI browser element you'll go to the corresponding panel or control in the editor. That's good!
There doesn't seem to be a way to go the opposite direction (i.e. from a control in the user interface editor to the corresponding item in the user interface browser tree) : this could be useful in case of complex UIR files with several panels and controls, especially if you have more than one control array in it.
So I suggest to add two options to the control context menu to locate the control in the UI browser ad to locate in a control aray if it is included in any of them.
I'm thinking to something like that:
It would be handy if these new items could be assigned a shortcut key too: ctrl+U and ctrl+R could be a good choice (presently ctrl+U is not used in the UIR editor and ctrl+R is not active at design time)
We have recently dropped CVI (as of 2009) as an option for use with our many data visualization applications. The graphic performance is just too slow and clunky to put up with any longer and gets worse as we add features or try to make 'native looking' applications (that resize, animate, etc).
Things like dragging/updating cursors is noticably clunky when you have more than one graph updating (linked cursors across more than one graph).
Updating datasets in large tables is slow enough to watch it step through the rows. Even using suggest tips like using ATTR_CTRL_VAL instead of SetTableCellVal, when a large table has to update... it's painfully noticeable. Basically any operation that updates a large portion of the UI.
Another example, try to resize and move controls (as most other applications do) on the EVENT_PANEL_SIZING?
I'm going to go out on a limb and guess that CVI doesn't use any graphics card acceleration? since workstation or netbook doesn't seem to make much difference in graphic performance.
Our clients notice when our applications look 'clunky' and 'slow' when compared to smooth, responsive apps/interfaces from competitors. It's often the little things that make a big difference in appearance.
While developing code, having correct indentations is very helping in making sure you have all the right brackets and to see where your structures are nested easily. Sometimes, whether by copying and pasting or just rapidly getting out a section of code, a whole segment might have incorrect indentation, which is tedious to correct.
This is where an auto indent tool could be a big time saver. From somewhere like the Edit menu, where similar functionality is located in other development environments, you could select Format Selection to do a highlighted section or Format File to do the whole file. Then, CVI can format the tabs for you:
Although this is a simple example, auto indent becomes even more useful when you have multiple nested structures and decide, for instance, to add or remove another nested loop.
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.
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.
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.
In CVI there are two kind of buttons:
But if you try to design a modern interface (like the MS Outlook 2010 ribbon, for example) you need a button where you can have both
Even in the new CVI 2010 SP1 there isn't a convenient workaround (see here, for example).
In LabVIEW, otherwise, this kind of buttons can be easily created.
An interesting feature would be also a setting to set the text position referred to the picture (top, bottom, left, right).
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.
I realize that there may be open source solutions for this but I would love a robust easy to use email function on completion. Essentially, I am gearing up to run some larger batched analysis routines on a remote workstation for our user group. The analysis time and queue length will vary from minutes to hours (hopefully not days yet). I would love the option to email the user on completion, failure, or email me if something really goes crazy.
The problem with the current simple email solution (unless authentication was really recently implemented) is that almost every SMTP server requires additional authentication to combat spammers I suppose.
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.