To avoid this I have found the Event Target must call a second method being the Event Handler.
I see you have
bindevent(0, WM_KEYUP, this, "GetKeyPressed")
If you changed this to
bindevent(0, WM_KEYUP, this, "GetKeyPressed_Event")
and added the procedure
protected procedure GetKeyPressed_Event
lparameters pln1 as Integer, pln2 as Integer, plnKey as Integer, pln4 as Integer, pll5 as Boolean
This.GetKeyPressed(pln1, pln2, plnKey, pln4, pll5)
endproc
It should avoid it.
It is a timing problem in VFP itself. The "this.Intellisense.Showed" is most likely the failing line. Intellisense is known to be part of the object, however the pointer to the "Showed" property is not available to the current place.
Please check the other BindEvent handlers too.
Comments: ** Comment from web user: TracyP **
Well, the problem isn't in the latest. I got a C5 in the old build I had been using.
I am not actively running any other tools. I have some home grown things that only run off the custom menu I load at startup.
I believe the problem has always happened when pulling a list of fields from an open cursor/table.
I opened a testing environment and began typing some code and got the error.
#include "C:\Program Files\Microsoft Visual FoxPro 9\foxpro.h"
CREATE CURSOR dr ( ;
field01 i, ;
field02 i, ;
field03 i, ;
field04 i, ;
field05 i, ;
field06 i, ;
field07 i, ;
field08 i, ;
field09 i, ;
field10 i)
at this point I highlighted the above Create Cursor and executed it. Then changed dr to drtest.
Then at the bottom of the window I typed dr. and got an error. It doesn't happen every time.
Why is it sometimes the #DEFINE show up in the list and other times they don't? I tend to have the problem more when they are appearing.