01-10-2014 09:20 AM
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.
01-13-2014 02:56 AM
#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.
01-13-2014 12:34 PM
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.
01-17-2014 03:53 AM
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!
01-22-2014 04:32 PM
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:
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.
01-23-2014 06:18 AM
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:
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
11-02-2014 07:09 AM
The issue has been resolved in CVI 2013 SP2