Range check error?

[CM630]

If you have to keep ErrorCode of type LongInt and using hex numbers in your case statement then you can use another unsigned variable to refer to the same memory occupied by ErrorCode using absolute:

Code: [Select]

function DAQmxErrorDescription (ErrorCode: LongInt): String;
var
  uErrorCode: DWord absolute ErrorCode;  //<----
begin
  case uErrorCode of  //<---
     $00000000: Result:='DAQmxSuccess';
     $FFFCCC73: Result:='ErrorCOCannotKeepUpInHWTimedSinglePoint';
...


Thanks, that works!

This is not a "bug" in FPC. $FFFCCC73 is just like it looks like... a positive number. I'm not aware of a simple automatic solution that FPC would consider $FFFCCC73 as a negative number (because it just isn't negative).
 

I would argue, that four bytes are nothing but four bytes until they are specified as something else. They could be a float number, but I suppose that the sign $ in FPC is what defines them as a unsigned integer number. Probably another character would define them as something else?
 

There are 4 possible solution you could use. (Edit: 5 with the one engkin provided above)

I like the fifth best, as it is most straight forward.

 

B.T.W. does the function DAQmxGetErrorString not give you the same results as your own function?
 

It could, but it's not localizable. Colleagues call me on the phone, trying to read something in English. But they cannot read it, and I cannot understand it.


 

Edit2: I found a list here and here. You'll see that the library uses real negative numbers (and not numbers like $FFFCCC73):

Code: [Select]

#define DAQmxErrorWriteNotCompleteBeforeSampClk                                    (-209801)
#define DAQmxErrorReadNotCompleteBeforeSampClk                                     (-209800)

....
You can find them all in NIDAQmx.h.

I do not remeber where did I took these from. Anyway, the entire functin is here.
Also, I added some info to the wiki.

[rvk]

I do not remeber where did I took these from.

It could be you took them from here. It is a translation of nidaqmx.tlb (the NI DAQmx C API) to pascal. But I think the conversion-utility which made this did not take into account that errorcodes where signed long integers and should be negative for errors (and positive for warnings). It just translated the "32 bit space" to a 32 bit unsigned long integer (which in my point of view is not correct according to the National Instruments libraries).

It should have been like:

Code: [Select]

const
  DAQmxSuccess = 0;
  ErrorCOCannotKeepUpInHWTimedSinglePoint = -209805;
  ErrorWaitForNextSampClkDetected3OrMoreSampClks = -209803;
  ErrorWaitForNextSampClkDetectedMissedSampClk = -209802;
  ErrorWriteNotCompleteBeforeSampClk = -209801;
...
etc.
Like it is defined in NIDAQmx.h by the National Instruments libraries itself.

But anyway... the solution you use now works too.

They could be a float number, but I suppose that the sign $ in FPC is what defines them as a unsigned integer number. Probably another character would define them as something else?

No, it's not the $ what makes them an unsigned numer. Actually $FFFF1111 is not defined as negative or positive. It's just the same as 4294906129. So in that sense you would be comparing your ErrorCode to 4294906129 (which ErrorCode can never hold because it is too large). If you want automatic conversion you should either use LongInt($FFFF1111) or disable the range checking because that's what keeping you from comparing these values. With the absolute method you're essentially bypassing the range checking which is fine as long as you know what you're doing.

You would still have a problem calling this function like this:

Code: [Select]

showmessage(DAQmxErrorDescription($FFFCCC73));


[Leledumbo]

No, it's not the $ what makes them an unsigned numer. Actually $FFFF1111 is not defined as negative or positive. It's just the same as 4294906129.

And you can still prepend with + or - to make it positive or negative, respectively. Integer literals are by default 64-bit signed, operations around it will convert its type to the required one.

[CM630]

You would still have a problem calling this function like this:

Code: [Select]

showmessage(DAQmxErrorDescription($FFFCCC73));


Not anymore, thanks for the bug report:

Code: [Select]

...
function DAQmxErrorDescription (ErrorCode: LongInt): String; overload;
function DAQmxErrorDescription (ErrorCode: Cardinal): String; overload;

implementation

function DAQmxErrorDescription (ErrorCode: LongInt): String;
var
  uErrorCode: DWord absolute ErrorCode;
begin
  Result:= DAQmxErrorDescription(uErrorCode);
end;

function DAQmxErrorDescription (ErrorCode: Cardinal): String;
begin
  case ErrorCode of
     $00000000: Result:='DAQmxSuccess';
     $FFFCCC73: Result:='ErrorCOCannotKeepUpInHWTimedSinglePoint';
     $FFFCCC75: Result:='ErrorWaitForNextSampClkDetected3OrMoreSampClks';
     $FFFCCC76: Result:='ErrorWaitForNextSampClkDetectedMissedSampClk'; 
...
 

No, it's not the $ what makes them an unsigned numer. Actually $FFFF1111 is not defined as negative or positive. It's just the same as 4294906129.

And you can still prepend with + or - to make it positive or negative, respectively. Integer literals are by default 64-bit signed, operations around it will convert its type to the required one.

So it ia actually an absolute value. Things clear now, thanks for the help. I cannot rename the thread to [SOLVED], since it is not mine.