>>
>>It just seems to me that the documentation indicates that it (the parameter) must be a character string: "The expression must be passed as a character string." Passing a variable without the quotes is not passing a character regardless of the variable's contents.
>
>It depends what you want to evaluate (note that the same goes for Eval() and Type()). Whatever you pass to these functions must be a string (literal, variable, field, property, expression, function call). This string gets evaluated and its value or type of the value is returned.
>
>Look at this:
>lcX='Whatever'
>lcY='lcX'
>?type('lcx')="C"
>?type(lcY)="C"
>
>Both lcY and 'lcX' contain the same string, i.e. 'lcX', right? If we used Eval() instead of Type(), we'd be getting 'Whatever' both times.
>
>>What I think is happening here is that because the variable happens to be character (when containing just numbers) evaluates properly. However, when containing just letters it does not.
>>
>>If I were to describe this, I wouldn't call it a bug, but I would call it a "feature". Under the circumstances, I still hestiate to rely on this in the future.
>
>It's a feature, and a very good one. I'm using it for years, and trust me, I know what I'm doing. Imagine you had a string variable which contained a name of another variable - and you needed to know the value or type of that contained variable. Simply feed the name of the containing variable to these functions, and you got it. Look at this example:
>
>Lparam lpObj
>
>local lcVarName
>lcVarName='lpObj.value'
>?type(lcVarName)
>
>You could probably get something better with vartype(lpObj.value), but I'm not sure whether it would behave if there was no .value property in lpObj.
>
>And, btw, have a good, dark one :)

---

I second on that :) It's a good feature I use frequently too. ie :

for ix = 1 to fcount()
 if type(field(ix)) = "D" 
  store eval(field(ix)) to ("m."+field(ix))
...

Cetin