next »

[Huy H.]

What am I doing wrong here? It seems I cannot compile when an ACTION follows by both INFIELD and ATTRIBUTES.

Code

  INPUT BY NAME discount
    ON ACTION prefill { compiles ok }
--  ON ACTION prefill INFIELD discount { compiles ok }
--  ON ACTION prefill ATTRIBUTES(DEFAULTVIEW=YES) { compiles ok }
--  ON ACTION prefill INFIELD discount ATTRIBUTES(DEFAULTVIEW=YES) { ERROR }
--  ON ACTION prefill ATTRIBUTES(DEFAULTVIEW=YES) INFIELD discount { ERROR }
      LET discount = 10
    ON ACTION accept
      ACCEPT INPUT
    ON ACTION cancel
      EXIT INPUT
  END INPUT

http://genero.versaterm.com/BDL/3.20/#fgl-topics/c_fgl_dialog_ON_ACTION.html

[Rene S.]

Hello, this is a compiler bug/weakness.
When introducing ON ACTION action-name ATTRIBUTES() we excluded  ON ACTION action-name iNFIELD field-name ATTRIBUTES(). Why? The semantics was not clear. What happens in this example:

Code

ON ACTION foo INFIELD field1 ATTRIBUTE(DEFAULTVIEW = YES, TEXT = "abc", ACCELERATOR = "Control-X")
ON ACTION foo INFIELD field2 -- without attributes

What happens if the focus switches from field1 to field2? The answer should be: DEFAULTVIEW = auto, TEXT = "foo", no accelerator.

In 3.00.05 we have fixed: https://agile.strasbourg.4js.com/jira/browse/FGL-4140 ON ACTION ATTRIBUTES must belong to the sub-dialog.
That's a similar situation:

Code

DIALOG
    INPUT ..
        ON ACTION foo ATTRIBUTE ...
    INPUT ..
        ON ACTION foo ATTRIBUTE ...
END DIALOG

I've created this new bug:
https://agile.strasbourg.4js.com/jira/browse/FGL-5311 ui: ON ACTION ATTRIBUTES should be possible for actions with INFIELD clause.
Out of scope:
My instinct: the same action should have in any context the same attributes. It's kind of annoying to repeat the attributes when using an action more than once. For that reason: use action defaults, avoid action attributes in the 4GL code.
Use the ATTRIBUTES clause only for actions appearing no where else in your project.

[Rene S.]

I've overseen this existing bug:
https://agile.strasbourg.4js.com/jira/browse/FGL-4542 ON ACTION .. INFIELD does not allow ATTRIBUTE(S)
Anyway, don't expect any activity on this issue. There is no added value compared to regular action defaults - except your are really excepting different attributes in different contexts.

[Reuben B.]

Rene,

Did you consider the case of a one-off action where it is preferred to define all you need to with the ON ACTION, and therefore no need to touch a .4ad or .per.  In that case I think ...

Code

ON ACTION foo INFIELD field1 ATTRIBUTES(TEXT="...", IMAGE="...")
 

would be preferred to

Code

BEFORE INPUT
    CALL DIALOG.setActionActive("foo", FALSE)
BEFORE FIELD field1
    CALL DIALOG.setActionActive("foo", TRUE)
AFTER FIELD field1
    CALL DIALOG.setActionActive("foo", FALSE)
 
ON ACTION foo ATTRIBUTES(TEXT="...", IMAGE="...")

Reuben

[Rene S.]

Hello Reuben,
Yes, I did.
OTH: why adding extra code (setActionActive here and there) if on action infield exists? On action infield has been introduced for exactly this reason: simplify the 4gl code. The runtime controls the activation of actions.

If (hypothetically) the attribute clause would be supported for an on action infield then we end in the dilemma: the programmer must repeat all attributes for each action with the same name. This is the opposite of simple.

[Huy H.]

For us, this is sort of a one-of situation.  We have our action defaults defined in a 4ad file.  In this particular situation, we wanted the attributes of this action to be different than the defaults defined within the 4ad.  We've used INFIELD and ATTRIBUTES in the past, it just wasn't clear to us that the two cannot be used together in the code.  It's not a big deal really, we've found a work around that we think it's more intuitive to the user:  We added a button on the form next to the field (therefore DEFAULTVIEW = YES) and only used the INFIELD in the code.

Like Rene had alluded to, there's other ways that we can do to get to the behavior we desire, just that it wasn't obvious to us why the syntax didn't work.