>> Until I could see the whole code and prove it's something else how could I say that.
>>One thing I learned in fox these years is that actual error point might not be the line debugger is coming up with or the actual error message might be different.
>
>Since I don't have debug info in my distribution exe,
>I can see only that error occurs in MYINKEY() procedure: exact line number is not shown. Is it possible that ANY line in the following function can cause this error in ANY conditions? Exact code is:
>
>func MYINKEY
>priv tul
>on error NOTE
>tul = inkey()
>do seterror
>if type('m.tul')!='N'
> return .f.
> endif
>return m.tul == 27
>
>I have a form. In form activate there is
> on key label F2 do myproc
>
>myproc calls a prg file which contains sql
>selects and scan loops.
>prg file calls this function.
>
>procedure seterror is
>
>proc SETERROR
>#if 'Visual' $ vers()
>if version(2) = 0
>#else
>if empty(getenv('debugging'))
>#endif
> ON ERROR DO syserror WITH LINENO(), lineno(1), message(1)
> && I know that using message(1) in error rountine parameter
> && here returns incorrect line
> else
> on error
>#if 'Visual'$ vers()
> set asserts on
>#endif
> endif
>return

---

Hard to debug :) When some error happens that drive me crazy I prefer to test it with all "on error" routines cleared (just on error), set assert etc are all at their default. Exact line number is not shown and that's the problem IMHO. In fox2x days it was really driving me crazy for the point of error shown might be a read...show statement. Real error was something in @say,get or show routine.
I don't know. I never faced with an error with inkey() on my own. I searched the KB and found only one entry relating MAC.
Cetin