>BTW, this came up in the thread and in my mind. Since my VPD App is completely dependent (editing) on my Event Handlers (Grid Like). I'm going to see how difficult it would be to create a class for those procedures. The Event Loop is basically an inkey() with functions for every keystroke (sometimes Mouse is trapped, but pretty useless in FPD, better just to turn it off). What I don't have clear in my mind is how the Dialog Box that I create would be created in VFP.
>But I guess I won't know any of this until a try, that's how it all got written in the first place.

Yes you need to see all by yourself. It's hard to grasp the pointers at first when moving from fox2x, anyway here are few:
-Though VFP is an OOP not everything is OOP and procedureal code still has a place.
-Inkey() is one of the functions that you should quickly forget (as well as on key label). Keypress event replaces it (do not take any of "replaces" as a true and radical "replace" - even some functions from fox2x today has a use but in help are simply marked as "included for backward compatibility use X instead" while there is no credible replacement really:)
-As I said earlier consider when/valid are missing (and a side suggestion -set flamesuit on-forget there is a valid event in any object-set flamesuit off-).
-Dialog box. Not clear what you mean by it. If wait window, modal screen etc then they have much better ones (messagebox(), inputbox(), modal forms -which might even be created on the fly-, etc).

"To create a class for procedures"
It's very easy. ie:

*myProcs.prg
procedure X
*...
Y(...)
*...
endproc
Procedure Y
*...
endproc

Becomes (assuming no procedure name collides with custom's built-in methods:

*myProcs.prg
define class myProcs as custom
  procedure X
  *...
  this.Y(...)
  *...
  endproc
  Procedure Y
  *...
  endproc
enddefine

Cetin