Counter question:
Your asking for the right GUI event indicates a lesser abstraction level of application design.
If you want to track an event as a data change, you normally will do so on the database level with an update trigger, which foxpro DBCs also offer.
The next level would involve testing for changes right before saving them to the underlying database on the data access layer, or in the business logic layer, eg via a combination of table/view buffering, getnextmodified and getfldstate.
And if all these abstraction layers are too late you'd need to catch the gui event. But checking against rules or triggering some additional behaviour upon change of some value done on the most upper GUI level is always less portable later in N-tier design.
The thought I bring up is, take care where you put the reaction to the data change. If the action you will take in the form is in the data, you may better do it in the data layer. If the action is influencing the GUI in the first place, you may be right, but then again you may rethink the GUI as merley being the representation of data and no matter how you put the GUI and how it reacts to changes, it's the data the users interact with and change and save and work on. It's the data that is the value of a databased application, more than the GUI, so you may change the data, trigger other data change through this and update the data representation to do whatever you intend to do in a less direct way.
Making the GUI the most clever part of your application never has paid in my experience. That causes effeorts to reimplement that GUI behaviour logic in other GUIs, which may come later, while putting it to the database layer is making it reusable to any other GUI made on the same data. The intermediate business logic layer may also be the right place for the code reacting to the value change. Not seldom you will want to only save to the database, if changes as a whole, not all the single changes, then an immediate reaction cannot be put into the database, but you can do so in the business logic layer.
Some even say, make both the database and the GUI dumb, let the GUI just represent the data and the database just persist it. I say the data integrity also is important and that doesn't reflect best with a dumb database. You need referential integrity rules and transactions and mostly will have stored procedures to encapsulate many things happening on this level near the value of your application, the users data.
Perhaps this gives you some totally different ideas and approaches. Perhaps this is far over the top for your needs, you don't tell us what you want to trigger in case of the grid cell change.
Bye, Olaf.