CVI 9.1 Taskhandle type casting build error

[octy88]

In previous versions of CVI (< 9.1) I was able to do the following without getting an error.

int task;

DAQmxCfgSampClkTiming (task, "", rate, DAQmx_Val_Rising,
                                       DAQmx_Val_FiniteSamps, sampsPerChan);

Now the same code generates an error since the first parameter (task) is of type TaskHandle.

Since I got a whole a library using an int instead of type Taskhandle I rather not change my source

code at this point.  Is there a quick way to disable this type of error?

[muks]

What is the exact error message that you are getting?

[octy88]

Error:

  Function DAQmxCfgSampClkTiming expects parameter 1 to of type Taskhandle (i'm passing an int)

DAQmxCfgSampClkTiming

The prototype for DAQmxCfgSampClkTiming

int32 DAQmxCfgSampClkTiming (TaskHandle Task_Handle, char Source[], float64 Rate, int32 Active_Edge, int32 Sample_Mode, uInt64 Samples_Per_Chan);

The problem is the variable I'm passing to  "Task_Handle" is of type "int". 

 I know how to fix it: DAQmxCfgSampClkTiming( (TaskHandle)myVar, ....). 

My question is why does the same code works without generating an error in previous versions of CVI (< 9.1)

but now the exact the same code fails to compile.  In the past I believe TaskHandle was just a typedef of int but

now its a typedef of "void *".  I know the real fix involves a modifying my code (a whole library) to use "TaskHandle"

instead of any int but I would like to know if there any way possible of disabling this type of error checking in CVI.

[EricS.]

Hi octy88,

There is no inherent way in CVI to overlook these compiling errors, the functions are expecting a certain type and the functions themselves are throwinging the error.

There are two things you could do, both do require modifying your already existing code.

1.  Type cast the int as a TaskHandle which you did and know it works.

or

2. Change your definition from int to TaskHandle.  

I would be surprised if the issue was actually be with CVI itself.  When you did your upgrading, did you also upgrade the NI-DAQmx Drivers?  It would normally be within these drivers that the function expectations are set.

[octy88]

Eric based on experience I will have to disagree.

This code has been in used since 2006 and the type used is "init".  It has compiled, build, and run

without any errors.  In 2007 I upgraded the DAQmx driver (last quarter 2007) and it still worked.

Now two of my co-workers have begun using CVI 9.1 (one with the lates DAQmx) and now the

exact same code generates errors.

The correct thing to do to change all "int"s to "TaskHandle" and at some point it will be done.  However,

the task is rather lengthy and time is currently of a premium.

This is not first time I seen this type of errors.  Code that compiled before will all of sudden report an error

due to a type mistmatch.  The proper programming technique is to used the same type but many times

I inherit the code from someone else and I don't realize there is a potential problem since no errors are

appearing during compiling.

[Mert_A.]

Some typedefs were changed when adding support for 64-bit binaries, and I'd imagine this is one such case. In order for the code to be portable across both 32-bit and 64-bit architectures, some types had to change from a fixed 32-bit integer to a void * or intptr_t type, which is 32 or 64 bits, depending on the target architecture. When you upgraded to the more recent DAQmx driver, you got a newer header which changed the underlying type of the TaskHandle type.

One of the reasons that the DAQmx library uses a typdefed TaskHandle type rather than a naked int is exactly to provide a level of abstraction to isolate users from implementation changes that might need to be made. If you don't use those types, there is nothing we can do to protect you.

As you said, the correct thing would be to fix the code to use TaskHandle variables instead of plain ints. If you need a stop-gap solution, I would suggest modifying the TaskHandle definition in the DAQmx header file to define it as an int instead of void *, making sure to fully document this as a temporary workaround in the source.  As long as you only build 32-bit binaries, this should work. If you upgrade DAQmx again before fixing your code, you'll be back in the same boat again.

Mert A.

National Instruments