Win SDK function conflict with CVI library function

[menchar]

I do not have  SDK_CONFLICT_PRIORITY defined.  Is this new to CVI 2009?

The following code gives me an error  "11, 58   Too many arguments to `CVI_WriteFile'."

#include <windows.h> 
#include <formatio.h>  

void function (void) {
   
    HANDLE hHandle = INVALID_HANDLE_VALUE;
    char buffer [1000] = {'\0'};
    DWORD dwWriteCount;

  if (!WriteFile (hHandle, buffer, 5, &dwWriteCount, NULL)) {
        ;
    }
}

 
I have included  <windows.h>   before   <formatio.h>  but CVI still wants to use the formatio version of WriteFile - it appears to have been renamed   CVI_WriteFile  ?!?!?

If I eliminate the #include <formatio.h>  it compiles OK.

Message Edited by menchar on 03-06-2010 04:00 PM

[RobertoBozzolo]

I happened to observe the same behaviour on GetFileTime between windows.h and utility.h.

Basically, CVI include files sometime define functions with the same name as windows API ones, so the corresponding include file should take care of it. In my release of formatio.h (as of CVI 8.5) I can see

#ifdef _NI_mswin32_
extern int CVIFUNC      cviprefix(WriteFile)(int handle, const char *buf, int count);
#else
 

where cviprefix is defined in cvidef.h as follows:

#define cviprefix(c) CVI_ ## c

So, the CVI version of WriteFile in windows environment is renamed as CVI_WriteFile and since formatio is included last this is the function which is used. Simply #undef-ining WriteFile immediately after including formatio.h should solve your problem by restoring original definition in windows.h.

[ebalci]

Well, I am still confused since menchar already uses the SDK version WriteFile in the code.

formatio.h just redefines the name to CVI_WriteFile when there is already the SDK version defined.

I thought the reason formatio.h prefixes the function name is to let both versions live together, right?

This should not be effecting any existing WriteFile usage. It should only prevent compiler errors if CVI_WriteFile is used.

I am not familiar with the way prefix is added using the macro, but I believe it does not change all the function codes in the code.

The compiler gives error at the line where WriteFile is used and says that it is a CVI_WriteFile.

Yeah, still confused.. 🙂 

[RobertoBozzolo]

Well, the complete source for formatio.h I reported before is this one:

#ifdef _NI_mswin32_
extern int CVIFUNC      cviprefix(CloseFile)(int handle);
extern int CVIFUNC      cviprefix(OpenFile)(const char *filename,int rd_wrt, int action, int bin_ascii);
extern int CVIFUNC      cviprefix(ReadFile)(int handle, char *buf, int count);
extern int CVIFUNC      cviprefix(WriteFile)(int handle, const char *buf, int count);
extern int CVIFUNC      cviprefix(SetCommitMode)(int commit);
#define CloseFile       cviprefix(CloseFile)
#define OpenFile        cviprefix(OpenFile)
#define ReadFile        cviprefix(ReadFile)
#define WriteFile       cviprefix(WriteFile)
#define SetCommitMode   cviprefix(SetCommitMode)
#else
 

In the header this warning is present:

/* This header must be included after any Windows SDK header or any header */
/* that directly or indirectly includes a Windows SDK header.              */
/* Some of the function names conflict with Windows SDK functions.         */
 

As far as I can understand (but I'm not an expert on these very technical and tricky aspects of C) first of all CVI functions are renamed CVI_xxx, after it a call to WriteFile or any other function in that group is defined to be translated to CVI_WriteFile, so when you call WriteFile the preprocessor actually translates it in the CVI version of the function and SDK one is superseded.

My understandment is that if you undefine WriteFile, you can actually use both functions if you want: native CVI one by calling CVI_WriteFile and SDK one by simply calling WriteFile.

...or I can be missing some other hint, which can surely be possible!

[ebalci]

---

Roberto Bozzolo wrote:

...
extern int CVIFUNC      cviprefix(WriteFile)(int handle, const char *buf, int count);

#define WriteFile       cviprefix(WriteFile)

... 

---

Now, it makes sense...

So "WriteFile"s are really replaced with "CVI_WriteFile"s.

[LuisG]

Menchar,

You need to include <windows.h> before <formatio.h> in order to resolve the naming conflicts, but this doesn't mean that the conflict is resolved towards the SDK version of the file. The conflict is still resolved in favor of the CVI function.

However, if you define SDK_CONFLICT_PRIORITY in the Build Options dialog (yes, this was added in CVI 2009, then the conflict will be resolved in favor of the SDK function. The full explanation is in the WriteFile function reference help.

To summarize, these are the results depending on what you include:

1.

#include <formatio.h>

Result: you get the CVI function

2.

#include <windows.h>

Result: you get the SDK function

3.
#include <windows.h>

#include <formatio.h>

Result: conflict error - you always get an error, even if you don't use the conflicting functions in your program

4.

#include <formatio.h>

#include <windows.h>

Result: you get the CVI function

5.

#define  SDK_CONFLICT_PRIORITY 1

#include <formatio.h>

#include <windows.h>

Result: you get the SDK function

Luis

[menchar]

I resolved the problem by using    #undef   WriteFile

after the include of formatio.h

But, CVI documentation would have made me think that by including windows.h first that I might have then automatically deconflicted the overloaded function names in windows.h and the various CVI libraries.

But that's not true.  Including windows.h first does eliminate the very many other conflicts that exist, but doesn't resolve the conflicts on these Win32 SDK function names.

It looks to me as if NI has tried to clean this up a bit with the macro  SDK_CONFLICT_PRIORITY

but this forces the resolution to be all CVI or all SDK functions.  

It's still a problem if you need to use some of each.

But then, how could this type of conflict ever be resolved automatically?  There would always be ambiguity.   In some cases you might want the SDK function and in others the CVI library function.  It so happens that in my case I usually want to SDK function but not always.  So I should have thought this through more carefully before posting the question.

At one point I thought it was careless of NI to have overloaded the function names, but then someone at NI pointed out that CVI's use of these function names preceded the existence of windows 😉

Menchar

[RobertoBozzolo]

Hi Luis,I do need some clarification on your explanation.

Has the standard in including been changed with CVI2009 introduction? I'm puzzled with your case #3, which is what I am doing at present and which does not generate any conflict in compilation (I'm using 8.5). Including windows.h on top of all #includes has been a rule till now (and is stated in some #include files as I reported some post ago): does this mean that all code written in previous versions of CVI needs to be rearranged in this respect?

[menchar]

Yup, I wonder about case 3 as well - I don't think that's what's happening with CVI 2009.

[LuisG]

Oh, boy... Looks like I managed to make this even less clear. Here is what I meant to write. Sorry for the confusion:

3.
#include <formatio.h>

#include <windows.h>

Result: conflict error - you always get an error, even if you don't use the conflicting functions in your program

4.

#include <windows.h>

#include <formatio.h>

Result: you get the CVI function

Menchar,

As far as the documentation is concerned, "resolving the conflict" didn't imply resolving it in favor of the SDK version of those functions. It simply meant "making the compiler error go away". The new macro now allows you to pick one versino or the other. But you're right, if you want to mix the two, then your only choice is to split up the code into multiple files where you can define or not define the macro, depending on your preference. It's not an ideal situation, but I don't see any other alternative to this problem.

And yes, it's true that the CVI function names are older, but both packages are at fault, in my opinion, for not "prefixing" those names from the start. 

Luis