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.
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.
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
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.
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.
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.
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...
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:
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
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
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
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.
As CVI evolves (in age and functionality) I feel that additional efforts are required for maintaining the product, i.e, keeping it 'consistent' and avoiding a 'mosaic look' as if assembled by different engineers in different decades...
A simple example but also one I would like to see resolved is entering data types in the UI editor vs in a function call (PlotIntensity in this case):
So, for example, long long translates to int64... Why not simply use the identical terms??
I agree it could be worse but I also feel that this is a valid suggestion for future improvements...
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.
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.
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
Right now if multiple controls are selected you cannot jump to the code with "View control callback" menu option or Ctrl+B accelerator even if they have the same callback. It could be handy to be permitted to go to source if selected controls have the same callback.
Consider this scenario:
On a panel you create two buttons, select both of them and edit their properties assigning a (unique) callback to both. Next with both controls selected you generate the callback using "Generate Control Callback" or Ctrl+G. Now you would like to go and code something in the callback but you're not allowed to: you need multiple clicks to go to source: one click anywhere on the panel to deselect controls, one to select one of the buttons and finally the right click or accelerator key. Not very handy...
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.
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.
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.