next_record in text item trigger [message #662295] |
Mon, 24 April 2017 03:30 |
|
Mary@kaefer
Messages: 6 Registered: April 2017
|
Junior Member |
|
|
Hi,
I have a form with a tabular block having 3 text items (Lower Limit, upper Limit, amount). Data entered in Upper Limit text item should be displayed automatically as the value in lower limit text item of next record . I tried the same with key_next_item trigger. But the same is not working when the cursor moves from the text item by mouse. Please advise me how to do it.
Thanks in Advance,
Mary
|
|
|
Re: next_record in text item trigger [message #662298 is a reply to message #662295] |
Mon, 24 April 2017 04:36 |
cookiemonster
Messages: 13961 Registered: September 2008 Location: Rainy Manchester
|
Senior Member |
|
|
And that's why key-next-item should only ever be used for navigation.
Also if you use key-next-item that means that you're automatically creating a new record in addition to the one you're entering, which is bad design.
Use when-validate-item on upper limit to store the last entered variable in a non-database datablock item (or a global).
Then use when-new-record-instance to assign that valur to lower-limit (check you're not in enter-query mode).
|
|
|
Re: next_record in text item trigger [message #662299 is a reply to message #662298] |
Mon, 24 April 2017 04:43 |
|
Mary@kaefer
Messages: 6 Registered: April 2017
|
Junior Member |
|
|
This logic work for new records. Suppose the block has following records
Lower Limit ---- Upper Limit---Amount
0 ------------ 1,000---------10
1,000----------- 2,000---------20
2,000----------- 3,000---------30
Now, when the user tries to change the upper limit 1,000 to 1,500 on first record, automatically the lower limit of second record should be changed. I can save the new upper limit 1,500 in a global variable, but when I can assign to the next lower limit ?
[Updated on: Mon, 24 April 2017 04:44] Report message to a moderator
|
|
|
Re: next_record in text item trigger [message #662309 is a reply to message #662299] |
Mon, 24 April 2017 08:11 |
joy_division
Messages: 4963 Registered: February 2005 Location: East Coast USA
|
Senior Member |
|
|
First of all, how can the same number be a lower limit and upper limit?
If you want to do something like this, you need to save the value into a variable before changing it, then when updating the value, update the database for the matching lower limit, then re-query the block. However, that is just not a good practice.
There really is no correlation between on row and another row, other than the fact that the upper of one row matches the lower of another, which previously stated is not correct, but it seems your "bug" will make it easier to find the row to update.
And what if the upper limit is changed to something greater than the upper limit of another row?
[Updated on: Mon, 24 April 2017 08:12] Report message to a moderator
|
|
|
|
Re: next_record in text item trigger [message #662314 is a reply to message #662310] |
Mon, 24 April 2017 12:43 |
joy_division
Messages: 4963 Registered: February 2005 Location: East Coast USA
|
Senior Member |
|
|
What is "previous row" and "next row?" I do not see any sequence number. It "looks" like you match an upper limit to another rows lower limit, but I wouldn't rely on that. You need to define a relationship between rows.
Like I said, you will need to update the database then re-query the block. Maybe in when-validate-item, and putting the condition that it is an existing row and not a new row.
|
|
|
|
Re: next_record in text item trigger [message #662324 is a reply to message #662322] |
Tue, 25 April 2017 02:42 |
cookiemonster
Messages: 13961 Registered: September 2008 Location: Rainy Manchester
|
Senior Member |
|
|
Lets say up front that forms really isn't designed to allow you to modify a different record in the block to the one ther users are currently in.
On a technical level this is because you ideally need to use a restricted procedure - next_record - from the only trigger that's guaranteed to fire when you edit an item - when-validate-item - and it's not allowed.
Thing is, execute_query is restricted too, so I'm not sure how the trigger plan helps and it adds the extra complication of having to avoid a mutating table error.
Whenever I had to do anything remotely like this in the past I just insisted that the users had to press a button to sort the data out.
What I would probably try is this:
when-validate-item: record upper_limit and current row number in non-database datablock items
form level when-new-item-instance:
IF upper_limit currently held
record current item/row in local variables
go to row one higher than one recorded by WVI.
set lower limit
go back to item that initially caused WNII to fire
clear non-database datablock items
END IF;
|
|
|