Cetin,

> I don't understand quite well though where do you call that code (on key interception?)

As usual, thank you very much for your help! You're probably confused because my description of this topic may not have been as well written as I would have liked. (Truth be told, even I'm confused!)

My goal was to be able to display a shortcut menu at the current cursor (caret) position in a textbox or editbox control. Non-mouse users would invoke the popup via the Shift+F10 keystroke consistent with other Windows apps that provide a keystroke shortcut alternative to rightmouse click for invoking context menus.

So, my challenge became how to figure out where the cursor (caret) was relative to the current form. Your GetCaretPos() code from 2001 and, surprisingly, row()/col() could be used to determine the exact position of the caret. In this situation I found row()/col() better because these functions return foxel based values that the define popup command requires for specifying a popup location.

So far, so good :) ... then I realized that when a user repositions the cursor (caret) via the keyboard or mouse that GetCaretPos() and row()/col() values are NOT updated. This meant that my shortcut menus would often popup in the wrong location. I googled this behavior (cursor keys and mouse not updating GetCaretPos) but could not find anyone else complaining about this so my guess is that this behavior is specific to VFP.

In my research and experiments I could find no way for GetCaretPos() or row()/col() to update their coordinates unless I entered a visibly displayed char. So my "solution", er hack :) was to give these functions their little visible char - for just just a split second - to force their coordinates to resynch with the physical location of the caret - and then to take away that temp char and restore the control's value to its original state. All this under the cover of LockScreen = True.

Conclusion: An ugly solution that appears to work in all my test cases. Worse side effect is when cursor is in bottom right of an editbox and the temp space key forces the scollbar to advance forward. The effect is visually disconcerting (the user sees a mysterious scroll), but the GetCaretPos() and row()/col() coordinates are synched properly and a popup menu will appear in the expected position.

Does this answer your question?

Best regards,
Malcolm