You could use VAL(TRANS())

>VFP7 SP1
>
>Dear Friends
>
>I'm going round in ever decreasing circles here until I'm likely to disappear down my own foxhole. I've had this problem in the past and I suspect it may be a bug. I've just muddled on till I get no more complaints then worry that it's not properly fixed, and will crop up later in production. Consider the code snippet below, esp. the lines labelled && (1) & (2):
>
>

>LOCAL	lcFilter, I
>
>With thisform
>  lcFilter    = "AP_ID = " + ALLTRIM( STR( .nAPID)) + "and not DELETED()"
>  Select CENAPFLD
>  Set Filter To &lcFilter
>  Locate
>  I           = 1
>  Scan
>    .lstAPFields.AddListItem( AP_FIELDCAPT, I,  1)
>    .lstAPFields.AddListItem( ALLTRIM( STR( AP_FLD_ID)), I,  2)
>    I	    = I + 1
>  Endscan
>  Locate
>  .lstAPFields.Selected( 1)	= .T.
>  .nAPFldID		= VAL( .lstAPFields.ListIndex( 1, 2))  && (1)
>*TPMcD*	  .nAPFldID	= .lstAPFields.ListIndex( 1, 2)        && (2)
>Endwith
>

>I have to rely on the value of thisform.nAPFldID. I had problems with the .lstAPFields( I, 2) being stored as a val, so I STR()'d it.
>I set .nAPID to VAL() of this.
>It seems that. depending on the compiler's mood, lines (1) or (2) will return a "data type mismatch" error. As I change from one to the other there's always a knock-on effect later on when, say, in the IRChange() method of the list box I do the same assignment to .nAPFldID
>
>Anybody come across this before, or know a way out?
>
>TIA
>
>Terry