Some older versions are still visible on specially Debian and derivatives(because these versions are default in that Debian Stable).ДЇor Delphi of course there are more versions in active use because a new version must be bought (in the Eur/$ 500-600 range). Typically the two last versions of Lazarus are in active use (1.4.4 and rc's for the upcoming 1.6). Both work in FPC and Delphi, though inttostr might require a object oriented (Delphi alike) mode in FPC.ДЄ string is not an object btw, but a first class native type.Д«asically Lazarus/FPC and Delphi are the only really active native Pascal products. does the function DAQmxGetErrorString not give you the same results as your own function?Д®dit2: I found a list here and here.As said there is inttostr, which is Delphi's way of doing it. (but your still comparing unsigned with signed variables which isn't good)Д«.T.W.

You could temporarily disable the range check error.

The ErrorCode will become a positive value which you can compare.

Use a cast around the variable ErrorCode.

This is probably the next best thing because the numbers are turned negative with LongInt() and you're comparing them correctly That way the high errornumbers are converted to negative numbers so you could compare them correctly to a LongInt.

Use a cast around the errornumbers (with LongInt($FFFCCC73)) like you did in your last post.

This is probably the way it should be but I'm not sure if you have a list from the library stating those $FFFFxxxx numbers.

Convert the $FFFCCC73 numbers to real signed long integers (like -209805) like the National Instrumens libraries stated they are.

(Edit: 5 with the one engkin provided above) There are 4 possible solution you could use. 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 still think it's weird the National Instrumens libraries state the result is a signed long integer but your comparing them to positive numbers (like $FFFCCC73). $FFFCCC73 is a positive number (unless you cast it to a LongInt like you did in your last case-solution).

In that case I'm puzzled where the value $FFFCCC73 comes from. These indeed state that the result is a signed long integer. But in that case you shouldn't compare it to an unsigned value like $FFFCCC73. if the function where the errorcode comes from defines that if a negative error is returned it is an error then an signed long integer is the correct variable. After that also change the LongInt in your function to Cardinal or LongWord and now your using the unsigned 32bit everywhere (without getting any range check errors).Д«.T.W. So look everywhere in your program where you are getting this errorcode back from some function and change the variable of that errorcode to a Cardinal or LongWord ( or whatever is defined by that function). You could use LongInt($FFFCCC73) in your case-statement but I wouldn't recommend it.

You see it defines the result as LongWord or Cardinal and not as LongInt because it can't put $FFFCCC73 in a LongInt without getting a rangecheck error there too. Where in your program are you assigning this value $FFFCCC73 ? Is this coming from a function you made or an existing function? Look at the definition of that function. If you're comparing a variable to values like $FFFCCC73 you should make sure your variable itself is a unsigned long integer too (and not a signed long integer like you're using now). Where does FPC consider your LongInt to be unsigned? You are trying to compare your LongInt to a value which can never be in a LongInt.

Free pascal longint