LabWindows/CVI Idea Exchange

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

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)

 

Where does NI stand on this????

NI no longer supports 32 bit OS, but hasn't ported their own toolkit to x64. Since NI is NOT committed to developing (or even maintaining) CVI toolkits, how about open sourcing these so that users and the community can move these forward.

Can you add new argument for CVI CLI (i.e. ...\CVI2013\compile.exe)

which will dump the build output to a file (similar to the -log LOGFILE argument) ?

current options provide only PASS/FAIL for the compile without providing enough information 

In cvicc (CVI compiler for Linux), there's an option -DDEFINE to define a macro, but no equivalent -U to undefine it. It would be useful because the macros defined in [Options][Build Options][Compiler defines] are indeed used by cvicc when compiling on Linux. If I need a project-level macro defined on Windows but not on Linux, I don't know how to remove it except by parsing it out of the prj file before compilation.

 

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

I would consider it useful if the Build Output would state the total number of errors in a file - right now it says: 1 file with errors, but especially if you start with many errors I find it helpful to see if a change in code reduces the error count.

 

To my knowledge earlier versions of CVI provided this information, which disappeared with clang integration.

 

Related posts are here and here

The most recent version of the C runtime that comes with the Phar Lap ETS is msvcr90 from 2008. That really restricts the usage of more recent third-party libraries on real-time targets shipping this operating system.

 

Support for msvcr{100,110,120,140}, even with stubs for most of their functions, would be greatly appreciated.

Coupled with the Source Code Browser, there should be a 'Refactor' option to rename an identifier to something else. And only that one, not the homonyms from other contexts, which is something impossible to achieve with a search and replace.

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.

Hello,

 

I don't know if it is possible technically but from a user's perspective it would be convenient for debugging a program (in debug configuration) if the UI constants could be provided in the data tooltips, too. Right now, if something is wrong with my UI I will have to do a lot of detective work to find out which control / control attribute is the problematic one...

 

Example: Consider the code

 

SetCtrlAttribute ( panel_handle, control_id, control_attribute, attribute_value );

 

Right now, if I hover over attribute_value, the tooltip will display something like "attribute_value = 24064". Then I will need to look up userint.h to find out which attribute value this is ( ATTR_CTRL_VAL ). It would be more convenient if the tooltip could include this information, too, and display something like "attribute_value = 24064 ( ATTR_CTRL_VAL )"

 

The same holds for control_id, because a number such as 14 will not immediately help me - I will have to go through the corresponding include file to find the respective UI control (e.g. TABPANEL_2_NUMERIC ).

 

 

Wenn ein Rechner nicht am Nezt ist, vielleicht das Kabel nicht richtig drin oder am Platz kein Netz mehr frei ist, dann wird CVI mit einer eingeeschränkten Testlizenz gestartet und würde dann eine EXE generieren, welche in der Laufzeit eingeschränkt ist. Oft ist es der Fall, dass jemand CVI ohne Netzt started um im Quelltext etwas zu kontrollieren. Zu einem späteren Zeitpunkt erstellt jemand eine EXE neu und bemerkt nicht, dass das gestartete CVI keine Lizenz hat, obwohl der Rechner Netz hat. Er müsste erst CVI neustarten um die Lizenz zu holen.
Den Fehler bemerkt er erst am Folgetag, wo das Programm mit einem Fehler abgebrochen wird.
Es wäre aus meiner Sicht sehr sinnvoll, dass eine EXE, welche durch CVI ohne Lizenz erstellt wird, auch einen Popup mit eingebaut bekommt, welcher hiervor warnt.
Auch eine Abfrage, welche der Progrmmierer in sein Programm einbauen kann wäre sehr Hilfreich.

A byte array is limited to 2GB because the index is an int. Allow the use of long for an index so large arrays can be used.

I'd really appreciate a warning for "empty bodies" or whatever it is called, i.e. things like

 

for(...);
while(...);
if(...);

 If written like

if(...) { };

 it is OK.

 

Tiling windows is only possible, when they are released from the IDE before. But navigating between the IDE and the released windows is difficult. It would be nice if the sourcecode and uir windows could be tiled INSIDE the IDE. Could look like this:

tiledwindow.JPG

The JIT debugger option in CVI 2010 is a nice step in the right direction, but only being able to debug builds that were compiled in "Debug" mode pretty much defeats the whole purpose of the idea. Debug builds are much too slow to be used in production and on my machines, if I ever use a Debug build, it probably already runs under the debugger anyway! Seeing that CVI is not even an optimizing compiler I cannot understand why release builds cannot be properly debugged. 

 

Thing is, the crashes in production are the important ones that I absolutely need to be able to investigate, and CVI does not provide ANY assistance in this area apart from being able to at least generate a MAP file. This is what I currently have to do: I have included code in my application that creates a memory dump and sends it to me when the application crashes or hangs. This dump I can then load into WinDbg and with a few tricks I can at least import the CVI MAP file to get some functions names in the stack traces, but that's it, all investigations have to be done on the assembly level. To quickly decipher stack frames, e.g. to have a look at local variables, I often even have to throw my OWN code into a disassembler (IDA Pro)! I'm really glad that this way I am now at least able to debug most crashes at all, even when they happen far away in a different country, but this aren't the 80s anymore and you can probably imagine that this process is hard and time consuming and very much annyoing. With code compiled in VC on the other hand I can load a MiniDump and have a look at the stack trace, variables and code on the source level without much hassles. 

 

Some ideas that could help:

 - Let me (JIT) debug release builds

 - Let me load MiniDumps into the debugger or

 - create PDB files that I can use together with a debugger that can load MiniDumps (WinDbg, VS)

 - Let me not only use an external compiler but also an external linker that generates PDB files for release builds (I don't like this solution as I use C99 features VC does not support, but I'm desperate here)

 

Okay, rant over for now, I think I really needed to vent a bit. Thanks for reading this far 😉 

 

All the best, Marcel 

The C preprocessor in other compilers has seen some improvements over the years. Maybe you could freshen the CVI one up a little bit. With most modern C compilers there are some pretty advanced things that can be done in the preprocessor. But include those header files into a CVI project, and you start getting errors in the strangest places. And the cause of these isn't even some nasty trick, but pretty basic stuff for any other preprocessor.

Currently the 'long double' type has 64 bits of precision, which is the same as the 'double' type.  It would be handy on occasion to be able to use the full 80 bits of precision like is available with the Intel compiler.

In principle CVI supports external compilers for an optimized release version such as Intel's ICL and I managed to successfully compile release versions using ICL 11.1.

 

However, documentation on this issue is sparse.

 

It is even worse if one attempts to use an external linker which might be appropriate if one attempts to use e.g. Intel's MKL. Here I would love to see the support of external linkers in combination with an improved documentation.

 

Similarly, CUDA is becoming more attractive for more demanding floating point applications - I would consider it very useful if NI could provide e.g. an application note of how to do this in an easy to follow tutorial.

well, the title says it all: extend the current partial support of C99 standard to full support

Hi,

 

I would like to see an configuration of batchbuilt process. I have a big workspace with many projects; and would like to create different setups, like "compile only all server projects" or "compile all client projects". The workspace contains a big server-client -based software packages; some dll-projects used for server side only, some only client side.

 

Peter