LabWindows/CVI Idea Exchange

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.

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.

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.

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