Carl -
I appreciate the "suggestion"; however, I have never used the @message function because it is barely visible and somehow, no matter how important it may be, I never think to look there. Now, if a certain designer would like to give us the option of placing a "message" OVER an LE - limiting the size of the message to the size of the LE - THAT would be a WONDERFUL enhancement for version 2.0. lol
My date of birth and date of anniversary are on a separate (called Special Events) tab, along with the age and years. The age/years is only important to me if the Special Events tab is in view. Perhaps there is a way for me to program something that will work for me based on that condition.
For me, the main issue is still (as you said) that I don't want the on form change programming to be triggered based simply on the recalculation of my age and/or years LE's.
Erika -
I understand the examples you gave about wanting to execute programming based on a change in an unbound element; however, in each of the specific examples you gave, I believe that I would find it easy enough to simply have the programming execute based on element exit. Even if the statement had to go in more than one field, that is not like having to insert programming for 77 fields.
As for your stat gflag suggestion, assuming it works for what I need, and it looks like it will, I would still have to deal with it in my age/years LE's but more importantly, in every single command button on the form (and perhaps other instances that just don't come to mind right now) and for every command button I add to the form. Once again, that seems like a lot of extra work to me. Nevertheless, it may not be as bad as I think and I'll certainly give it a shot.
I cannot help but feel that there has to be a better solution. Just as the distinction has been made whether or not to give the "warning" notice when the only change is in an unbound LE, so too do I think there's a way to provide for what I want and still be allowing the individual user to make individual choices based on their individual needs - but to make doing so
easier.
I mentioned earlier a "switch." Suppose for example I could use an @LE function (not a switch but this would work too ... in switch form - I would simply follow my programming with someting like /LEB or /LEU):
@LE(Bound,Last Updated = @date )
@LE(Unbound,Last Updated = @date)
giving me a choice of whether the on-form-change programming executes only when a bound le is changed or only when an unbound le is changed. If neither is specified - meaning I just dont use the @LE portion of the programming, then the default would be the current state of considering both bound and unbound LE's as triggering a form change.
and perhaps another option of
@LEIGNORE(Birthdate;Anniversary)
where I can chose all but the specified fields to trigger the programming.
These suggestions would not take anything away from people who are happy now with the way things are; They would not have to learn anything new nor would they have to do anything different than what they are currently doing. For them, everything would be just as good as it now is.
But for the customer (me and maybe even one other person - lol) who is not happy, I (or we) would have an easy-to-use, viable, means of "grabbing control."
Once again, I am looking to have the best of both worlds; flexibility (as we both agree) for the user to have control when wanted BUT coupled with ease of use in implementing that control.
25 MORE DAYS!