LabWindows/CVI Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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.

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.

Code refactoring is a common need for C developers and availability of eiter automated or semi-automated tools can be really helpful.

Since LabWindows/CVI now uses llvm+clang, probably a tool like "include-what-you-use" can be integrated.

This is the github page for the tool.

 

From the documentation:

"Include what you use" means this: for every symbol (type, function variable, or macro) that you use in foo.cc, either foo.cc or foo.h should #include a .h file that exports the declaration of that symbol. The include-what-you-use tool is a program that can be built with the clang libraries in order to analyze #includes of source files to find include-what-you-use violations, and suggest fixes for them.

The main goal of include-what-you-use is to remove superfluous #includes. It does this both by figuring out what #includes are not actually needed for this file (for both .cc and .h files), and replacing #includes with forward-declares when possible.

 

Here you can find this topic discussed in LabWindows/CVI forum.

Hello,

 

I am wondering if it would be useful to redefine the CVI callbacks using the const type qualifier to remind users that the parameters are read only, a strategy I use for all of my own function declarations as an extra safety measure.

 

E.g., instead of the current situation

 

int CVICALLBACK PanelResponse (int handle, int event, void *callbackdata, int eventdata1, int eventdata2)

 

have it declared as

 

int CVICALLBACK PanelResponse (const int handle, const int event, const void *callbackdata, const int eventdata1, const int eventdata2)

 

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.aspx

 

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.

 

 

 

 

Hello,

 

I've used the serial port call back for many years, and it works great.

 

The XNET driver would benefit greatly for at least a receive call back function, and possible even a transmit call back function.

 

This would make communication with automotive ECUs easier to implement.

 

Regards,

 

Terry Moss

Robert Bosch

Charleston South Carolina

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.

 

Thanks!

 

 

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.

When you have a function to install a callback, for example InstallMainCallback, NewAsyncTimer, InstallComCallback, viInstallHandler, DAQmxRegisterDoneEvent, DAQmxRegisterEveryNSamplesEvent, DAQmxRegisterSignalEvent, etc... it would be nice if the prototype was inserted directly in the source code by pressing Ctrl-D like for variables. Currently you have to open the documentation and do some copy/pasting.

As discussed here and here, CVI does not re-open workspace files in the order they were when CVI was closed; I am referring to confined workspace, not freely floating windows.

 

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.

 

Thanks!

Hello,

whereas it is possible to add, remove and rename a folder in the project tree via a right-click popup menu it is unfortunately not possible to rename a file.

Instead one has to remove the file (plus its accompanying include file) from the project, rename it in Windows File Explorer, and then add it to the project again.

It would be more convenient being able to do so within the project tree, similar to the ability to rename folders.

Hello,

 

it was very nice to see clang updated to version 3.3 in CVI2015; I wish this support of current versions of clang will be continued in the future, so I am hoping that with CVI2017 we might get clang 3.9 or 4.0 because of the following issues:

- many many bug fixes in clang

- improved diagnostics

- support of C11

- full support of OpenMP 3.1 and beyond

 

Thanks!!

Hi,

 

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:

http://forums.ni.com/t5/LabWindows-CVI/Forcing-DPI-Virtualization/td-p/3079742

 

Thanks.

Hi,

 

sometimes vertical buttons or toggle buttons fit better to the rest of the UI than the standard horizontal buttons. In such cases I would like to have the possibility to have the button text aligned vertically. Hopefully the attached figure can explain my wish...

 

vb.jpg

I think it would useful to allow for a progress bar control type in a cell of a table.

 

This could be done manually by loading different canned images into the cell, which would be stills of a progress bar in motion.  But that's cludgey.

If a file is listed in a project, but it is doesn't exist anymore on the filesystem, CVI doesn't mark it in any way in the project tree.

If the file is an .uir, this brings to a strange behavior with "Find UI object" (see here).

I think that files non-existent on the filesystem should be marked mark in some way (color, special icon, ...) in the project tree.

The check can be done when the user opens and closes the project.

I noticed that LabVIEW has two ways to download instrument drivers: direct downloads from IDNET and through the NI Instrument Driver Finder.

 

[NI Instrument Driver Finder Menu Option Image]

 

instr1.png


[Alternative NI Instrument Driver Finder Menu Option Image]
instr2.png

 

 

When downloading drivers directly from IDNET, the file must first be unzipped and then placed in the <National Instruments>/labview xxxx/instr.lib folder.

 

The easier option when working with LabVIEW, the NI Instrument Driver Finder, downloads the files, unzips them, and instantly gives you access to example code or palette of VIs for communicating with said instrument.

 

If possible, could we add a similar tool to LabWindows CVI?  It would be nice to have a menu option which would open a CVI Instrument Driver Finder.

 

The interface could then allow users to easily find a driver, download it to their Instruments Folder, see example code and start work.

 

Since probably 30% of all LabVIEW adoption comes from driver downloads and driver development, maybe this is an investment of resources worth looking into?

 

[Image of NI Instrument Driver Finder]

IDfinder.png

 

 

[Image of Instrument Driver Finder example code, project access, and palette access]

IDfinderexample.png

 

Cheers,


Shawn Shaw

This issue is that old that we all forgot about it... Smiley Wink

 

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.

 

Suggestion 1:

 

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).

 

Suggestion 2:

 

Complement the documentation, the idea is given below:

 

Constant: ATTR_WIDTH
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 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 Smiley Wink)

 

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...

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!