LabWindows/CVI Idea Exchange

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

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:

  • a shortcut to jump to the beginning of previous function in the same source file (CTRL + PGUP, for example)
  • a shortcut to jump to the beginning of next function in the same source file (CTRL + PGDWN, for example)
  • the current function where the caret is, displayed in the toolbar. It will be nice if you use a combo so that the user can jump to a different function with a simple mouse click (see attachment)

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.

As discussed here, distributing the code of

 

#include <ansi_c.h>
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.

support of Unicode character set would be most welcome

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

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.

Using CVI 2010 you can create different Custom Configurations

But I think that if a developer creates a new Custom Configuration (debug or release, x86 or x64), he wants to distribute it to a target machine. I don't create a Custom Configuration to have it run on my developer machine!

I've already asked to NI Support, and this can't be done in an automatic way.

 

So I suggest a new feature in the "Edit Installer" window to specify which Configuration (Default or Custom) to include into the installer (see attachments)

Download All

In the project window you can organize the project files into some "virtual" folders (Source Files, Include Files, ...)

If you right-click on the project name, you can add a folder with the item "Add Folder...".

If you right-click on one of these folders, you can add one or more files files.

 

But it's impossible to create a subfolder of one of these folders.

 

Every large project has a lot of files (sources, ini-files, images, icons, ...), so I think it's quite common having them saved into different "real" folders and subfolders. If you don't explicitly add these files to the project, you can add them to the distribution kit browsing your hard disk "real" folders, but in this situation the absolute path of the files is used. And if you move all your project from a PC to another one you won't be able to recreate the distribution kit without errors if you don't save the whole project to the same folder you use in the first PC.

And this is a really big problem.

For files explicitly added to the project, instead, the relative path is used, and this is OK, so the best situation is to add all the files in the project window.

So it's necessary create a full structure of virtual folders and subfolders.

 Hi

 

It would be nice for the distribution to be in one installer able file.

Which i could then send to a customer.

 

Regards

Shakeel

From the CVI Help:

 

Some Interface to Win32 Application Programmatic Interface (API) functions have the same name as some LabWindows/CVI functions, causing a naming conflict. You must include the Interface to Win32 API include files before the LabWindows/CVI include files. LabWindows/CVI automatically resolves the conflict by using the LabWindows/CVI implementation of the function. To use the Win32 API implementation of the function instead, define the SDK_CONFLICT_PRIORITY macro in the Compiler Defines section of the Build Options dialog box.

If you enable the SDK_CONFLICT_PRIORITY macro, you cannot use the following LabWindows/CVI functions and should use the Win32 API implementation instead.

Formatting and I/O Library

  • CloseFile
  • OpenFile
  • ReadFile
  • SetCommitMode
  • WriteFile

Utility Library

  • Beep
  • CopyFile
  • DeleteFile
  • GetFileSize
  • GetFileTime
  • GetSystemTime
  • SetFileTime
  • SetSystemTime
  • inp
  • inpd
  • inpw
  • outp
  • outpd
  • outpw

 

Based on my experience these name conflicts have no advantages, and create a lot of problems: usually I use the CVI implementation, but it happens that after some time I need the Win32 API implementation of one of these functions (GetSystemTime(), for example).

In this situation I must heavily modify my code, changing the calls to all the above functions.

 

I don't like these naming conflicts at all.

I suggest that a "_CVI" prefix (or something like that) is added to the CVI implementation: an old project will recompile perfectly simply adding this prefix to the calls, without modifications to variables, structures, ...

The additional columns of a tree can be hidden using SetTreeColumnAttribute() with ATTR_COLUMN_VISIBLE parameter. This is an easy and effective way.

For a table this attribute isn't supported, so you can use some workaround that requires more coding and have some disadvantages (for example if you set the width to the minimum value of 1, the user can increase it with the mouse...).

I think that the ATTR_COLUMN_VISIBLE parameter would solve this needs in the perfect way.

Right now, it is possible to add a readme file to the distribution (Build / Distribution / Edit...). Unfortunately, the file type of a readme file (and the license agreement file) is limited to *.rtf. 

 

It might be useful to distribute a more 'complex' readme file, e.g. including figures. Hence I would prefer to distribute readme.pdf instead of readme.rtf

 

It would be great if NI could provide standard translations of the NI runtime message file msgrte.txt in commonly-used languages.

 

Whilst we can get translations done ourselves, it is normally done by translators who have little knowledge of the runtime context so the quality is rather variable; also, I get the feeling that we are duplicating effort that may have been already spent elsewhere.

 

If it helps, I for one would be willing to pay for a decent translation.

I usually add a lot of files to my project (images, documents, ...) because in this way their path is taken as a relative path when building a distribution kit.

But in this way, if I press "Mark files in project" all the files are marked to search in, and so CVI gets a lot of errors for the files that can't be opened because they are not text files.

Using "Mark all c" and "Mark all h" extends the research also inside CVI installation directory, and (usually) this is not what I want.

 

I propose to replace "Mark files in project" with "Mark source files in project" or to add this last option to the existing ones.

We use the our development and target installation PC's to support both new and legacy projects that were developed under earlier versions of IVI Compliance.  As the only current way to change IVI versions is to uninstall and re-install, we are stuck using the earliest one as a common denominator.   With hundreds of old projects to re-compile, frequent across-the-board updates are not possible.  Newer versions of instrument drivers such as HSDIO are only compatible with later versions of IVI. 

 

I would like to have a reasonably easy way to switch IVI versions, so we can support both old and new code from our development PCs.  Even a batch file and some registry edit instructions would be better than the way it is now.  However, that would limit its use in a secure environment where the users don't have general admin privileges.

 

From an NI business perspective, this may be blocking customers from purchasing upgrades or new NI products.

It would be helpful if the distribution kit had three additional options;

 

  1. Compress all of the files and subfolders into a single *.zip file.
  2. An option to convert the *.zip to a self extracting archive (SEA) file *.exe.
  3. An option to automatically run "Setup.exe" after completing the file extraction from the SEA.

Option 3 is only available if option 2 is selected and option 2 is only available if option 1 is selected.

 

The above can be done with external tools and is helpful when distributing via a web-download, Dropbox or another internet based system. Installation for the end user is then simply a case of clicking a single link and running a single file. After that they are prompted by the usual installation dialog.

On my development machine, I have access to various library functions in the NI-Vision library.  Some of these functions apparenly require the NI-Vision Acquistion license, and some of these require the NI-Vision Runtime license, and some of these require no license.  They are all mixed together and I can find no documentation anywhere that tells me which license(s) I need to put on the deployed computers given what library functions I call in my application.  The only reliably way I have found to determine this is to deploy a test application to a PC that is not licensed and see if the function call fails with an ERR_UNREGISTERED.  It seems that there should be a better way.  Thanks.

It would be handy to be able to use some of the special variables like %CVIPROJDIR% and %CVITARGETPRODVER% in the "Edit Installer" dialog box, mostly so that the "Output directory" name can be autogenerated.  Thanks.

It would be nice if there was a library function to retrieve version information about an executable or DLL file.  I know this can be done through the SDK, but it's somewhat inconvienent.

 

Along the same lines, it would be nice if there was a library function to retrieve the version information about the currently running process.  (this would be great for making "About" panels in programs)

Using LabVIEW you are advised to use error codes from 5000 to 9999 and from -8999 to -8000 for user defined errors (none of the LabVIEW libraries use these ranges).

In CVI several libraries use different error code ranges, but there isn't any range explicitly reserved for user defined errors.

I think that this could be an useful feature.

If you select an User Interface control you can move it to a new location in two ways:

  1. through Arrange >> Control Coordinates you can set the new (X, Y) position
  2. moving it of a predefined offset every time you press one of the keyboard arrows, or of one pixel (SHIFT + arrow)

Using the arrows is an easy way if you want to move the control of a little quantity, but it's difficult if you need for example 200 or more pixels.

Moreover with Arrange >> Control Coordinates you can set the new location for a group of selected controls using the "All" buttons.

But if you want to move a group of controls of a desired offset you can only use the arrows.

 

I suggest the implementation of specifying either an absolute position or an offset throug the Control Coordinates window, both for a single control and for a group of them.