I have a field that resets when I include it, but if I change the record, it saves normally, I’ve already checked codes for errors, I’ve already removed the field and changed it again, deleted it from the database, revised the dictionary. I have no idea what else to do…
Oh, and I put message in the ?ok, after the “Process OK button in view only mode”, and it returns the correct value. without zeroing, that is, it is after the OK…
I am not sure there’s enough information in your description for us to know what problem you’re experiencing. Or else I’m extra slow today. 
1 Like
I’m confused. Include where? sort of sounds like a form procedure, but very ambiguous.
A bit more detail please, remember we’re not looking over your shoulder
1 Like
Yes, it is a form, a print is attached, to make it easier to see.
It’s just a field that resets, I’ve removed all routines and it keeps giving this error.
is the field Op. Fiscal, in blue
SOLVED!
JUST A IF, on a Accepted, I didn’t know that clarion ran all accepted before saving…
I did a check when inserting, in case there was nothing in that client, it took the default, and the default was ZERO.
1 Like
You can have your code only run in the Accepted event is when the user has NOT pressed the OK/Save button by using
IF NOT 0{Prop:AcceptAll}
!Accepted but not OK SELECT()
END
3 Likes
I didn’t know that clarion ran all accepted before saving…
It’s also worth knowing that, by design, the user can bypass code in the OK button.
Here’s how:
- Open the form and make some changes
- Press the button
- Answer “Yes” to the pop-up that asks whether to save changes or not.
Result? The modified record has been saved, without pressing the button.
Instead of embedding on ?OK, put the code in ThisWindow.TakeCompleted, before parent call.
I worked for a client who did not know this; they refused to let me change their code to fix the problem of gaps in their sequence of “serial numbers.”
N
I agree that you should not assume/rely on the ?OK button being pressed.
When the scenario @NickP describes occurs, the AcceptAll mode is still fired and the Accepted event is passed to all the controls.
Hi Nick,
This used to be the case, but some time go the ABC library changed so that instead of going to TakeCompleted directly, it now posts a Event:Accepted to the OK control. (In Legacy it just returns to the form)
So for a while now you’ve been able to embed code on the OK button, and it’ll work, even if the user ends the form with the X (or Cancel) and the “save record”.
3 Likes
I think Legacy and ABC work the same. You’re confusing Confirm Cancel with Offer to Save.
Legacy “Confirm Cancel” just returns to the Form if you answer NO.
Legacy “Offer to Save Changes” will push the Save Button (usually ?OK) if you answer YES, while CANCEL returns the the Form.
That “all accepted before saving” is not Clarion Per Se, it is a feature of the Form Template via the SaveButton Control template.
It does a SELECT() with No Parameters that starts the “Accept All” processing. Read about that in the Help on Select() and AcceptAll. When you create a Window without a SaveButton control template you have to hand code the SELECT() in OK and code Event:Completed if you want that feature.
One potential bug … it is not just a “Select() with No Parameters” that starts Accept All. Any Select(Something) that evaluates to Zero will do it. So it you miss the ?FEQ Question Mark e.g.
IF ~NUMERIC( Ven:PostalCode ) THEN
Message('Postal Codes must be numeric!')
SELECT( Ven:PostalCode ) !<-- Missing "?" so String will be (0) and cause Accept All
CYCLE
END
In the above you’ll see the Message. Then it will kick off another SELECT(), and you see the Message again forever.
The RTL should be fixed to overload Select() with a signature that has No Parameters.
That could work to prevent entering in AcceptAll unaware but changing the behavior of SELECT(fieldNumber) would break code using this form SELECT(0) or if it intentionally calls: SELECT(MyVariableWithTheFEQofTheNextFieldToSelectOrZeroToAcceptAll)
Perhaps a compiler warning (maybe with an option to disable that warning) could be an usesful feature without the risk of breaking code.
Yes it would break SELECT(0), but it would work as has been documented since CW 1 that SELECT() or SELECT is correct.
It would be easy to search for SELECT(0) and change it. Have you been using that or know of anyone that does? I think its worth the change as it is so easy to write the buggy SELECT(x) code.
It’s all moot as nothing is going to change in the RTL for this.
An enhancement that seems possible is to add an AcceptAll() function for simpler code:
Now: IF ~0{PROP:AcceptAll} THEN ...
New: IF ~AcceptAll() THEN ...
1 Like
Thinking it better about my suggestion of a compiler warning, it would be quite complex to be practical. To not raise false warnings it would need to alert only when finding SELECT(myField) without ? and myField being present on a Window declaration, in which scope? too complicated.
I believe I never used SELECT with (0) and I don’t remember having ever seen it. I think it’s unlikely anyone used in that way, having documentation, as you pointed out, stating clearly “with no parameters”. I’m just having caution about changes in these things.
To express it clearly, this is currently in Builtins.CLW:
SELECT(SIGNED feq=0, SIGNED pos=0, SIGNED endPos=0),NAME('Cla$SELECT')
You meant a “fix” conceptually in a way like this?
ClaSELECT(SIGNED feq=0, SIGNED pos=0, SIGNED endPos=0),NAME('Cla$SELECT')
SELECT(SIGNED feq , SIGNED pos=0, SIGNED endPos=0)
SELECT()
SELECT PROCEDURE(SIGNED feq , SIGNED pos=0, SIGNED endPos=0)
CODE
IF feq = 0
!silently do nothing
ELSE
ClaSELECT( feq , pos , endPos )
END
SELECT PROCEDURE
CODE
ClaSELECT(0)
I think that would prevent entering unaware in AcceptAll mode (but not selecting a wrong field if >0) when the programmer misses the ? in SELECT(?myField) . But it would have side effects too. It would obscure the presence of the bug, which otherwise if it happens, the developer or the user at runtime, seeing the bad behavior could report the problem, and the bug could be corrected to select the intended field. Also there are more than twenty functions in BuiltIns that receives a Feq (eg.ENABLE,DISABLE,…) and has this potential problem too. There is also a similar problem with REPORTs and missing SETTARGET nor using the extended notation.
yes, the example I opened in Legacy had a different setting set for the Message. So yes, in both cases it posts a message to the OK Button.