I have an editfield representing on hand quantity of a part. I wish to log when this value is changed. I set up a lost focus on it, figuring I could use the orig_text value as compared to the text value to see if it had been changed. But orig_text is empty. Nowhere in any of the properties or in @record can I find the original value. This seems so simple that I am sure I'm missing something, and I'm hoping someone out there can steer me in the right direction. TIA

Glenn,

LOSTFOCUS might not be a good idea. What if the user enters the field and changes the value more than once before he does a save, e.g, from "A" to "B" to "C"? Then "B" will be logged in addition to "C". I think the WRITE event must be better.

Regarding your problem of getting hold of the original value: I see there is an ORIG_ROWVALUE property (of the window, one must presume) that contains "the record read in the READ event". I've never used it myself, but one must assume it works.

- Oystein -

Thanks Oystein, I'll take a look at orig_rowvalue. In the example you gave of A being changed to B being changed to C, I actually want to log all such changes. The onhand quantity should never have to be changed, since a combination of sales and stock order receipts should take care of always having the current quantity, but in the real world there sometimes is a need to do so, so my customers want to be able to look at whatever changes were made.

OK, I just ducked out of here a moment to look at orig_rowvalue. That worked, seems to have all original values in it. Thanks again.

Oystein, a further question. I initially tried using the CHANGED event for the above purpose, figuring it would fire off after the user has changed data and then tabbed, entered etc out of the field. What a wrong assumption. How is the CHANGED event used? I noticed you had referred to it in a prior post and thought you might know.

Hi Glen

I remember trying a similar scenario where I only wanted processing to occur following a change in value. What I ended up comparing to was the GOTFOCUS_VALUE property for this control in the LOSTFOCUS event, which works everytime, so long as you RETURN the correct value EG.

modified=(GET_PROPERTY(controlName,'GOTFOCUS_VALUE') # GET_PROPERTY(controlName,'DEFPROP'))
IF modified THEN
  *** do your processing...
END

RETURN modified 

Glenn,

CHANGED seems to fire almost as often as CHAR - i.e for every keystroke that changes the value. So it's useless for your purpose.

- Oystein -

Glenn,

Just to be certain we agree: When I talked about "A" and "B" and "C"… …uh… …let's rather say 24, 26 and 25, since it's a quantity we're talking about, and not a text value… what I was thinking of was the following:

- The onhand quantity value is 24

- The user decides this value must be changed to 26 and does so

- The user tabs or clicks somewhere else in the form and does a few changes to other fields. Or just tabs or clicks somewhere else in the form without doing any changes. Anyway your LOSTFOCUS handler makes sure the changed value 26 is logged

- Then - before he's come as far as doing a save - the user thinks again, and realizes the quantity should be neither 24 nor 26 but 25

- He goes back to the field and changes the value to 25

- Satisfied he saves the row, and the LOSTFOCUS handler logs the new, correct changed value 25.

My question is: Should the erroneous 26 have been logged, being just a mistake that was corrected before the data went any further? This is why I think WRITE must be better than LOSTFOCUS.

A similar case would be the user changing the value but then cancelling the whole thing - doing a Delete Row or Clear. Again a value that wasn't used will be logged.

(If you're unlucky and careless there's also one case where your LOSTFOCUS will not run at all:

- The user changes the value and saves the row without leaving the field, i.e with a menu event

- That menu event doesn't generate a LOSTFOCUS event.

The built-in File | Save Row does generate a LOSTFOCUS event and causes no problem. But if you've made your own menu item for saving you should tick that item's Generate LostFocus event check box.)

- Oystein -

Oystein, thanks for the heads-up on the possibility of exiting w/o a lostfocus happening - I do indeed have my own exit set up in the menu and wouldn't have known about that.

Back on the 24, 26, 25 scenario, what I would actually record is that someone added 2 from the on hand qty, and then that someone subtracted 1 to the onhand qty. Obviously the concern here is the possibility of an employee modifying the onhand in an attempt to cover up the disappearence of an item. But being able to track the eventual resulting change is every bit as good as tracking multiple changes as in your example. Your input is greatly appreciated (altho not enuf yet for that housekeeping thing you mentioned earlier).

James, Thanks. I wasn't aware of the gotfocus_value - I'll take a look at it. That sounds as if it is what I was originally looking for - something that fires and says ' hey value X was just changed to value Y'.

That seems to be what the CHANGED event should do - I haven't yet been able to imagine any use for what it does do.

Glenn,

One possible use is for a while-you-type kind of lookup in a combo box. At any time all values starting with the string the user typed appear in the combo's list. E.g, the user types B, and all names starting with B appear. The user types an additional letter R, and only the names starting with BR show. Etc.

I guess CHAR could cover a lot of what CHANGED can be used for. But CHAR also fires when the user does keystrokes that don't change the value, like the arrow keys, Home, End, etc. In the example above CHAR could waste precious processing capacity by re-doing the list when not necessary.

- Oystein -

Glenn,

That seems to be what the CHANGED event should do - I haven't yet been able to imagine any use for what it does do.

We use this in at least two situations that I can think of.

First - We like to add information to the title bar of our database windows. For instance, in our Customers window we like to append the name of the current customer: Customers - ABC Corporation. This allows the minimized window to have the customer name in the tooltip and other areas where the operating system displays the information in the title bar. To achieve this, we wrote a generic routine called Update_Window_Text(). We simply add this the change CHANGED QuickEvent of whatever control we want to be used for this purpose.

Second - We have a dialog that requests parameters for a report. Often, a report on one customer/vendor is requested. We provide an editline where the customer/vendor number can be entered. Another editline (disabled) will display the customer/vendor name. Now, we do have a search mechanism that can be used. However, if the end user already knows the number (or thinks they do) they can simply begin typing in the customer/vendor number. As they do this, we have the CHANGED event take the number and update the disabled field with the name of the business dynamically. That way they have instant confirmation that they have the correct customer/vendor select for this report.

[email protected]

SRP Computer Solutions, Inc.

Glenn,

Visual Basic has an identical property to the CHANGED property in OI. Probably the biggest thing I use this event for, other than auto-text completion is for char by char validation.

Let's say there is a very tight parameter of allowable characters, the changed event allows you to validate each character as it is entered and either allow or deny that data entry.

Silly case of this is when using a text box to mimic a calculator routine. Obviously, only numeric and number formatting symbols should be used, at least if you're not supporting scientific notation. So, the CHANGED event would be used to reject any non-valid input.

HTH,

[email protected]

Greyhound Lines, Inc.

Glenn,

Visual Basic has an identical property to the CHANGED property in OI. Probably the biggest thing I use this event for, other than auto-text completion is for char by char validation.

Let's say there is a very tight parameter of allowable characters, the changed event allows you to validate each character as it is entered and either allow or deny that data entry.

Silly case of this is when using a text box to mimic a calculator routine. Obviously, only numeric and number formatting symbols should be used, at least if you're not supporting scientific notation. So, the CHANGED event would be used to reject any non-valid input.

HTH,

[email protected]

Greyhound Lines, Inc.

Thanks, Matt, Donald and Oystein - now I know what CHAR and CHANGED are for and why they do what they do.

Glenn,

That's fine. Knowledge is freedom. Perhaps.

But how's your logging coming along? Do you sometimes get more than one LOSTFOCUS per departure? See .

- Oystein -

Today's listening suggestion: Stomu Yamashta: Freedom is Frightening (Island) (1973)

View this thread on the forum...