Autoupdating defaulted fields

[lucidlee]

I have a fairly complex form with two date fields that between them define a

period. Both have defaulted values but the latter date may vary after extra

data is entered on the form. Since the defaulted value doesn't update itself

once created I've devised what seems to me to be a convoluted and clumsy way

to update the field afterwards with a script that is triggered by a button,

but it demands the field be off the form. So I have a calculation to display

the field value on form. This obviously isn't editable, which sometimes it

needs to be.

All in all I'm looking for a way to have an auto-updating, defaulted field

with a stored value that's editable. I'm wondering how others provide this

feature.

lee

[IdealData]

Create another date field that is enterable, and include this field in the calculation of the calculated date field.

If you lay the two fields on top of each other (top one transparent), then you can get the effect that the user can affect the calculated result, and would appear to be making entry into a calculation field.

[Ugo DI LUCA]

Hi,

A script by-pass the "not editable" settings of the Define Fields option.

So if your default date fields was entered as an auto-entered date field, you could call a script Update :

Set Field (yourdate, Today or Whatever date you want).

If the date default needs to auto-update based on some results, just set it as a calculation using a Case calculation :

Case("The ResultToCheck", your default date, Today)

[lucidlee]

ugo

Is there a way to control record updating so that when the user leaves the record it i s automatially updated. I would really like to ensure that the user always sees the current data and can edit it. Ideally the stored value would be updated as soon as underlying data is changed ie on exit from that field.

Lee

[Ugo DI LUCA]

Hi Lee,

What you're looking for seems very close to what Mark proposed then...

You could create a global field, and place it right behind the date field you want to modify. Set this field as totaly transparent (font and background)

Then define your date field as a whole button and call a script :

Set error capture

Goto Field (your global field, select)

Loop

End Loop If (StatusCurrentFieldName# "your global field"

Pause Resume (00:00:02)

End Loop

SetField (your date field, the global field)

Exit Record

[lucidlee]

Now that's very cool! I take it I should organise the tab order to visit the global field.

So to be clear:

1. On creation a calculated value, AutoDateTo, is defaulted into a field, DateTo.

2. The value of AutoDateTo may change as a result of data entry on that form and this needs to be reflected in DateTo.

3. Using your construction, a minievent loop is used to monitor and write the current value of a field into DateTo. This field could be a calculation such as if(isempty(global),AutodateTo,global)

So, as long as the Tab order visits the global before exiting the record I don't need to default the DateTo field on creation.

Lee

[cjaeger]

You can do it all without a script by - instead of using an auto-enter calculation - use an auto-enter lookup value bases on your record's serial number. So, if you crate a record, the auto-entered field contains exactly the value as in you auto-ente calc, but if other fields are filled, the results may be different.

to make sure the auto-enter updates itself properly, make the self-join key field

key=serialNumber & left(triggerfield1,0) & left(triggerfied2;0) etc ...

triggerfieds are the fields that should be monitored for values ...

[Ugo DI LUCA]

Hi Lee,

Now that you've explained what you were performing, I feel like Cjaeger idea could be appropriate.

If you really need to enter a specific date (not the current date) to trigger the update, then you would transfer to the front the global field (still transparent).

Keep in mind that in both cases, you wouldn't be able to perform a find from that layout, as either the script would activate when entering the date field or you wouldn't access to the date field that is at background.

And of course, if the calculation is based on the global field, make sure the global field is cleared at the end of script, or you will have strange results when creating new records.

[Ugo DI LUCA]

Hi Cjaeger,

I've never used this kind of settings, as I usually trigger a auto-lookup based on the Modification date. What is the advantages of your method compared to the other ?

In this case, I would have personally set the key and field to lookup like :

c_datetoenter= Case(Is Empty(global field), Autoentereddate, Global field)

c_lookupkey::serial num, where c_lookup key = (Mod Time * 0) + Serial Num.

[lucidlee]

Cjaeger

This is also an interesting idea. I suppose I could combine the serial n

[cjaeger]

The advantages are that the relookup is only triggered by specific fields.

Your method is more general and should be preferred.

however, there are situations when you do not want the relookup, only when a change in a specific field occurs.

[Ugo DI LUCA]

Thanks Cjaeger,

Hmm...locking re-lookups.

a number field n_locker (with 0 -unlocked and 1-locked)

the right side of relationship is changed to a calc field c_lookupcontrol = Case(n_locker = 1, Serial Num & " 0", Serial Num)

[cjaeger]

Thanks Cjaeger,

Hmm...locking re-lookups.

a number field n_locker (with 0 -unlocked and 1-locked)

the right side of relationship is changed to a calc field c_lookupcontrol = Case(n_locker = 1, Serial Num & " 0", Serial Num)

Yep - but ...

I often keep a price history in product inventorys - see attached file.

The advantage is:

History is updated -only - if a price update occurs!

relookup.zip

[Ugo DI LUCA]

Cjaeger,

Indeed !!

I was simplifying....but this is exactly the same reason why I looked to this "conditional locking lookup" !

And I'm also using it to lock lookup from prices (from the product file) when processing an entry in my Multi-line Item (to keep track of the price history for a given customer). If "net price" is not empty, no lookup from Product !!!

[cjaeger]

well, then look at it as an alternative method.

It may save you an extra relation.