I'm seeing that various programming is setting the @modified to true and thereby 'trashing' my 'modifieddate' LE.

For example:Exporting to csv using sbasic, using a button to display an image in an unbound image LE, etc.

The only solution I see doesn't seem to work to well:

Putting 'If @modified then modifieddate = @date' in each each relevent LE's 'On element change' works partially, but still not 100% accurate. What if a user accidentally makes a change and then fixes it before saving the form?

What I think would be ideal is something like this:

On form exit:
if @modified(Quality, Collection, part number, color name) then ModifiedDate = @date

Is there a way to accomplish this currently, for the most accurate use of @modified?

Also, does running a mass update trigger the @modified and other form programming?

Thanks,
Steve

Erika,

Thanks for the solution to my delimma, but I think my idea is much easier.

Maybe in a future release?



Thanks again for your help. I'll get started.

Steve

Wow, great advice and a great tip to keep in mind for my future programming work. (Although its not easy for a new Sesame user to pick up and run with, like my idea is.)

Good information, though.

Thanks! 

Steve

Steve,

Can you be more specific as to what is setting @modified. I've just tested a number of cases and the only case so far with any question is setting the label of a unbound static using the assignment operator (i.e. "LE0 = "New Label"), which does set @modified. But, for example, neither pressing an unbound command button, nor setting the label of an LE with label(), set the @modified flag.

Yes, changing the value of a bound LE and leaving the LE, then returning to it and setting it back to the original value, does leave the @modified flag set - and must. The @modified flag is singular, if Sesame sets it back, because one LE was set back to an original value, it would lose the fact that several other LEs may have also changed.

The @modified flag is intended to indicate if the form has changed, even if the user has no intent of saving the changes, thereby allowing the programmer to react to changes immediately.

It sounds like you could use a new function called something like @RecordWouldModify() that compares the current state of the form against the record still on the engine, before the form is committed. The difficulty in something like that is the amount of network traffic and complexity it would cause during simple form navigation - particularly in large forms with many subforms. Additionally, you could never tell if what is being compared is identical to the values actually committed because of subsequent navigation or form exit code.

Your idea to write a function that compares the values of multiple LEs is a good idea. But it also could only tell you if a value has been modified - not if it has subsequently returned to its original value. Nor could it reply which of the values of the LEs passed in have changed. The only way to tell if a particular value has been modified from its "engine original" value, is to keep the original value when it is received from the engine. That would require that all of the LEs be "shadowed" or duplicated in value, and that this duplication only occur when a form first receives the value from the engine.

This is not to say that I won't write such a function, but the difficulty becomes somewhat ponderous when confronted with table viewed subforms, where each LE may well have dozens or hundreds of values.

Quote:
This raises some other issues with ReadOnly fields. 

I have started a new Subject, Read Only fields at: http://www.lantica.com/Forum2/cgi-bin/yabb/YaBB.pl?board=gen_disc;action=display....

Quote:


I'll look into this. Maybe it is not being reset between the search spec and the results form.

Could you check @modified while you are populating the combo boxes in the retrieve spec? Put in a check in the retrieve spec programming before you do anything else and then additional checks as you make other function calls. Then put in a last check before any of the regular form programming run (in on form enter). That should tel us whether it is being set in the retrieve spec programming (and what call set it) and if it is simply not being cleared before the the main programming runs.

Quote:


WriteLn("Before Retrieve Spec Programming: " + @Str(@Modified))
WriteLn("After Populate Combo Boxes: " + @Str(@Modified))
WriteLn("After Retrieve Spec Programming: " + @Str(@Modified))
WriteLn("Before On Form Entry Programming: " + @Str(@Modified))