LabWindows/CVI Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
vix

Add "_CVI" prefix to functions with the same name as Win32 API ones

Status: New

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, ...

Vix
-------------------------------------------
In claris non fit interpretatio

-------------------------------------------
Using LV from 7
Using LW/CVI from 6.0
4 Comments
Wolfgang
Trusted Enthusiast

I like your suggestion! One might argue with backward compatibility, but actually the earlier such a change is implemented the less conflicts have to be resolved.

 

One could even suggest preceding all CVI functions with a CVI prefix - because the Win32 API might be extended in the future, or other libraries are included, too...

menchar
Active Participant

This has been a problem with CVI from the begginings of Windows.  To be fair, NI chose GetSystemTime() as their library function name before Windows even existed.

 

But, I agree, the library function name conflicts are a true hindrance, and the macro forces all of one or all of the other, which would never be the norm, where you most likely want to use some of each.

 

You can #undef  the function you don't want after specifying the header that contains it (either the CVI library header file or the windows.h file) so that the compiler picks up the function you want, but this is cumbersome as well. 

 

I don't think NI will ever change this, they don't want to break backwards compatability which they most likely feel is more important than your convenience.  Users have complained about this function naming conflict for many years and nothing has changed.

 

 

vix
Active Participant
Active Participant

I know that probably NI won't change it, but I hope they'll implement a way to choose between the two implementations for every function.

 

In this way it would be possible to use some implementations from the Win32 APi and some others from the CVI libraries.

 

I tried with some #undef but I haven't been able to do this.

 

Vix
-------------------------------------------
In claris non fit interpretatio

-------------------------------------------
Using LV from 7
Using LW/CVI from 6.0
menchar
Active Participant

It's not too hard hard, though maybe I confused things when I mentioned using #undef.

 

In general, the C preprocessor will use the last prototype found for a given function name when multiple prototpes are present.  NI may have effectively altered this behavior somewhat in order to give the user access to the Win32 SDK calls - I'm not sure how their new SDK_CONFLICT macro works.

 

But essentially I don't think you need to #undef the first prototype, just make sure that the last one found by the compiler is the one you want.

 

Specify the prototpe for the function you really want in the module (file) after all of the header files are specified.  Look in the windows.h or CVI library header for the prototype you want (either the Win32 SDK function or the CVI function) and place it in your source file after the header files but before you reference it.  If you want the CVI function, you shouldn't need to do anything (unless you've used the new macro to use the SDK functions when in conflict) since the CVI header is the last one specified. 

 

I've gone so far in the past as to go into the NI header file and comment out the prototype definition that NI is using to overload the SDK function, but I don't think this is necessary.