DIALOG issues

[Snorri B.]

Hi.

Assume you have an INPUT statement

Code (genero) Select Expand


INPUT BY NAME ...
....
  ON ACTION CANCEL EXIT INPUT
END INPUT


If the user presses cancel the Input statement is exits immediately without any any field validation. So the user can input any garbage into a field (like 1234 in a DATE) and then press cancel without getting the "Error in field" message. This behavior is different in DIALOG however. If you put the code above in a dialog:

Code (genero) Select Expand


DIALOG ATTRIBUTES (UNBUFFERED)
   INPUT BY NAME ...
    ....
     ON ACTION CANCEL EXIT DIALOG
  END INPUT
 
  ON ACTION CANCEL EXIT DIALOG
END DIALOG


In this case, the current field is validated and the user gets the "Error in field" error message. So the user has to clear the contents of the field before exiting. (This also applies to SUBDIALOGs)

Is this the intended behavior?

Thanks,
-Snorri

[Daniel N.]

Hi

in DIALOG it depends on the "validate" attribute.

Please have a look at:
https://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_prog_dialogs_action_validate.html

Best regards
Andrea

[Snorri B.]

Thanks Andrea.

Best regards,
-Snorri

[Reuben B.]

It is not really an INPUT versus DIALOG issue, it is buffered versus unbuffered.  With unbuffered the value entered is placed into the target variable and thus the checks occur that the value can be entered into the target variable

As well as the link Andrea gave you, have a look at explanation of buffered vs unbuffered
https://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_prog_dialogs_unbuffered.html

and I also like this link https://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_action_attribute_VALIDATE.html as it emphasises different ways of setting the attribute.  I'd expect you'd typically set validate="no" for actions with names such as cancel, help, zoom, wizard, delete, close, dialogtouched in your global .4ad.  You can see this in FGLDIR/lib/default.4ad

Reuben

[Snorri B.]

In my testing, a standalone INPUT BY NAME ATTRIBUTE(UNBUFFERD), will NOT check the variables, it exits immediately.
If you just put this into DIALOG, it will.

Regards,
-Snorri

[Rene S.]

Hi Snorri,
Andrea is right: your problem belongs to the validate attribute of the ACTION cancel.
Inspect the action-defaults:

Code (xml) Select Expand

<ActionDefault name="cancel" validate="no" text="Cancel" acceleratorName="Escape" contextMenu="no"/>

Why does not ON ACTION cancel validate the current field in a standalone INPUT? Any standalone INPUT has a builtin cancel action. This action never validates the current field. A user defined ON ACTION cancel inherits this behavior. ON ACTION cancel behaves like ON KEY INTERRUPT in the old TUI days.

Why does ON ACTION cancel might validate the current field in a DIALOG? A DIAOLG has no builtin actins. An ACTION cancel haves like any other ACTION: the attribute VALIDATE controls if or if not the current field must be validated before executing the actions code.

BTW: (minor, side remark)
Don't code like

Code Select Expand


ON ACTION CANCEL EXIT DIALOG

Replace ON ACTION CANCEL by ON ACTION cancel, replace EXIT DIALOG by CANCEL DIALOG.

Code Select Expand


ON ACTION cancel CANCEL DIALOG

cancel is not a keyword here. The compiler simply reads: "ON ACTION action-name" where action-name is a simple identifier.
Avoid EXIT DIALOG, use CANCEL DIALOG. CANCEL DIALOG performs the same cleanup as the builtin cancel action of standalone inputs does.

Rene

[Snorri B.]

Thanks Rene.

This CANCEL DIALOG is new to me. There almost no mention of it in the docs (only in dialog.cancel()) I'ts not listed as one of the dialog commands.
https://4js.com/techdocs/fjs-fgl-manual/#fgl-topics/c_fgl_ui_syntax_proc_DIALOG.html

Excerpt:

where dialog-statement is one of:
{ statement
| ACCEPT DIALOG
| CONTINUE DIALOG
| EXIT DIALOG
| NEXT FIELD
   { CURRENT
   | NEXT
   | PREVIOUS
   | field-spec
   }
}

[Sebastien F.]

This is a certainly a documentation bug.
We need to clarify what is the difference between EXIT DIALOG and CANCEL DIALOG.
Note there is no CANCEL INPUT for singular INPUTs, only ACCEPT INPUT and EXIT INPUT.
Seb

[Richard H.]

BTW: (minor, side remark)
Don't code like

Code Select Expand


ON ACTION CANCEL EXIT DIALOG

Replace ON ACTION CANCEL by ON ACTION cancel, replace EXIT DIALOG by CANCEL DIALOG.

Code Select Expand


ON ACTION cancel CANCEL DIALOG

cancel is not a keyword here. The compiler simply reads: "ON ACTION action-name" where action-name is a simple identifier.

The Genero Studio default preference for "Automatically convert all keywords to upper case" is set to TRUE.  Because of this Genero Studio sees the word 'cancel' as a keyword even if it is used where an action name is expected and capitalises it.

Your comment, Rene, would seem to indicate that there is a bug with the syntax checker in Genero Studio.

I am using Genero Studio version 3.10.10 build-161228.

Regards,
Richard.

[Rene S.]

I don't know how Studio detect keywords.
Yes, Studio should not automatically shift the case of keywords used as identifiers.

About the case "ON ACTION cancel": Simply try the auto-completion. o<tab> completes to ON, ON a<tab> completes to ON ACTION, ON ACTION c<tab> proposes nothing.

Rene

[Reuben B.]

Richard,

The issue you raise with Studio happens with ALL keywords.

Try typing

Code (genero) Select Expand

DEFINE form, begin, end, to DATE

and

Code (genero) Select Expand

MENU ""
   ON ACTION insert
   ON ACTION update
   ON ACTION delete
END MENU

and note that from, begin, to, end, update, delete, insert are all uppercased.  In simplistic terms if you have the preference enabled, as you finish typing a word ie a space, Studio is looking to see if the word is in a list of keywords, if it is upper case it.  There is a little bit of logic as it can detect if you are in the middle of a string and not upper case, but not a great deal of logic.

If you are participating in the Genero 3.20 EAP which is on now, you will see that there is a new code beautifier, and that is clever enough to detect keywords when they are used as keywords and upper case them appropriately.  Interestingly that code has to compile cleanly in order for the code beautifier to do its thing.  So if you have not already, please sign up for the EAP https://4js.com/download/eap/ and provide feedback on the code beautifier and other new features.

Reuben

[Richard H.]

Thanks Reuben, sounds good.  I look forward to seeing it in action.

[Rene S.]

To avoid wrong expectations:
Yes, the formatter upshifts keywords (since 3.20.01: downshifts keyword optionally)
But: the formatter can not change "ON ACTION CANCEL" to "ON ACTION cancel". The formatters reads the identifier "CANCEL" and does not touch the case. BTW: this could eventually be the subject of a new compiler warning: don't use uppercase identifiers being keywords in another context.
Rene

[Richard H.]

I would typically type:

on action cancel cancel input

and leave the capitalisation to the formatter.  The result is this:

ON ACTION CANCEL CANCEL INPUT

Be aware that users of Genero Studio may suddenly be seeing hundreds of compiler warnings where this sort of thing has happened and will probably choose to ignore the compiler warning in preferences rather than go and fix the errors (and potentially have to fight the formatter to stop it re-capitalising the word).