Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Detect change when change grid data

Status
Not open for further replies.

hwfehr

Programmer
Jun 18, 2007
2
CA
I have a grid in which I want to change the numeric value in a particular cell. If this value changes I would like to detect the change so that some code will be executed. I have tried When and Valid without success. Any help will be appreciated.
 
If you mean you are changing the value programmatically, than you need the ProgrammaticChange event.

Conversely, if you want to detect a change made by the user, then it's InteractiveChange.

In both cases, the method in question is that of the textbox within the column within the grid - not of the grid itself.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy
 
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.
 
Oh, I forgot to ask a concrete counter question. It would be "Is the GUI really the right place to react to the grid cell change?" or "Do you really need to react on the value change of some database table field on the GUI level?".

Bye, Olaf.
 
What I want to do is similar to the GotFocus/LostFocus feature which one might use to detect when data had changed in a TextBox. The data in the grid's column is numeric and is edited in the column itself. If the data in the column is changed, the value in a different field of the same table is changed.
 
Looks like you talke about computed data, eg a sum. You don't need lostfocus or interactivechange. You need buffering and getnextmodified getfldstate or oldval(), newval() and the alias.field value to check for changes. And if using buffering you don't depend on this to be done the moment the grid cell changes, but you can of course.

Mike has answered that already, don't use the grid events, use the textbox events of the textbox in the grid.

Bye, Olaf.
 
I want to change the numeric value in a particular cell. If this value changes I would like to detect the change so that some code will be executed.

Another way would be to use the When & Valid methods of the Grid's Textbox that you want to check.

Record the original value through the When method
ThisForm.WhenValue = This.Value
NOTE - you would have to add a WhenValue Property to the Form.

Then in the Valid method check the current/new value
IF This.Value # ThisForm.WhenValue
<do whatever>
ENDIF

Good Luck,
JRB-Bldr
 
What I want to do is similar to the GotFocus/LostFocus feature which one might use to detect when data had changed in a TextBox.

That's exactly what I told you, in the second post in this thread. To repeat: use the InteractiveChange.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top