LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

2013 include error

My LabWindows 2009 project includes a .H file from a UIR file and it compiles and runs correctly as expected.  I migrated to LabWindows 2010 and then 2012 without issue.  However, with LabWindows 2013 the compiler includes a different.H.  My UIR is named Control.UIR which created the include file Control.h, but LabWindows 2013 includes

C:\Program Files\National Instruments\CVI2013\sdk\include\control.h instead of the one in my project.  The #include statement appears to not care about the first letter being capitalized or not.  My work around is rename my UIR and H files to non-conflicting file names.  Is there something I am missing?

 

Thanks.

0 Kudos
Message 1 of 7
(4,674 Views)
#include <control.h>

searches for control.h in the include paths of your project,

 

#include "control.h"

does first search in the project source directory and then, if not found, in the include paths.

 

So, while you can change all #include to the second form and it should work, I recommend renaming to a unique, non-generic name.

-----------------------
/* Nothing past this point should fail if the code is working as intended */
0 Kudos
Message 2 of 7
(4,583 Views)

Unfortunately using quotes or brackets in the #include statements makes no difference.  Renaming the file is our current best solution, but we're still curious why we had this include issue.  Thanks.

0 Kudos
Message 3 of 7
(4,554 Views)

Hello Moxcoak,

 

I tried to reproduce the issue you described but wasn't able to experience the exact symptom. I tried this by creating a user interface CVI application from template, with a Control.h header file.

 

From my understanding of your symptom description, your build of the project is always failing, regardless of the way you include the header in your source file. Is this true? For example, in CVI 2012, replacing #include "Control.h" with #include <Control.h>, would cause the build to fail with synxax errors for instance, because the compiler would use the SDK header file instead of your project file. Is this an outcome similar to what you are seing in CVI 2013?

 

It would be also helpful for us to know whether you have any specific build settings enabled or any include paths set in your project settings (Edit » Project » Edit Project Dialog » Include Paths...).

 

Thank you!

0 Kudos
Message 4 of 7
(4,439 Views)

The key to the problem is that my project has source files in one subfolder and the Control.h file in another folder.  The Control.h file is included in the project (listed on the left hand side of the LabWindows/CVI window).  LabWindows/CVI 2012 finds the correct Control.h, but LabWindows/CVI 2013 does not.

 

I created the following simple project to induce the error.  Follow these steps in LabWindows/CVI 2012 with the Windows SDK installed:

  1. New project named Test1.prj in an empty folder.
  2. Create a source file named Test1.c with 1 line of code [#include "Control.h"] and put in it in the same folder.
  3. Add it to the project.
  4. Compile the Test1.c file and I get the expected compile errors since it found the control.h files in the SDK folder.
  5. Create an include file named Control.h with one line of code in it [#define ABC 20] and put in it in the same folder.
  6. Compile the Test1.c file and compiles without error as expected.
  7. Now create a subfolder named Source and move the Test1.c file into it.
  8. Replace the Test1.c file in the LabWindows/CVI project to point to the moved file.
  9. Compile the Test1.c file and compiles without error as expected.

LabWindows/CVI 2012 works since it finds the Control.h that is in the project.  Now repeat the process in LabWindows/CVI 2013.  It fails in step #9 above.  Even though the Control.h is part of the project, the compiler appears not to find it if it is not in the same folder as the .C file being compiled.

 

Nothing is listed in the "Include paths" feature of LabWindows/CVI.

 

I hope this makes sense.

0 Kudos
Message 5 of 7
(4,352 Views)

Hello Moxcoak!

 

Indeed, the steps you provided make sense. This helped me reproduce the symptom you are experiencing on your machine. The 2 important details were the following:

  1. The source file (Test1.c) had to be located in a subfolder relative to the project folder.
  2. In order to build the project successfully at the last step (9.), Control.h has to be added to the Project Tree. Otherwise, the build fails in CVI 2012 as well.

 

In CVI 2013, is also looks like, that adding the header file to the Project Tree or adding the path of the header file to the project include patch doesn't work, unlike CVI 2012, were the build succeeds at step 9. if at least the path of the header file is added to the project include paths, when the header file isn't present in the Project Tree.

 

Unfortunately, we don't have a good workaround for this issue, other than renaming your header file at this point, until this issue is fixed in an upcoming release or Service Pack. You can monitor this issue using this ID: #446782.

 

Thank you and sorry for the inconvenience!

- Johannes

0 Kudos
Message 6 of 7
(4,327 Views)

The issue has been resolved in CVI 2013 SP2

0 Kudos
Message 7 of 7
(3,645 Views)