next »

[Huy H.]

We are getting ourselves in a bit of a pickle with this issue.  Here's a bit of background.  Traditionally, we've been using BUTTONEDIT for our user to enter and store coded values.  For example, a vehicle type could be stored as "C" in the database to represent a car.  With the recent enhancement to Genero's COMPLETER attribute, we've made changes to our BUTTONEDIT widgets.  Now we display both the code and the translation in the input fields, and user can either enter "C" to in the field, or enter "Car" if they prefer the translation value.  Now our BUTTONEDIT content looks like this: [C - Car]

In the AFTER FIELD block, we parse the code from content of the form field, so the above will result in input_record.vehicle_type = "C".  This is all fine in situations where we are dealing with simple inputs where we either accept or abort inputs -- because ACCEPT INPUT automatically triggers the AFTER FIELD code.

The situation that we are running into is in the example below, where this is part of a bigger input:
Vehicle Type [C - Car]
Vehicle Color [          ] [Search]

Suppose the user just type Car and select "C - Car" from the list of suggestions.  At this point, without leaving the current field, the user clicks "Search" -- Search requires you to input both values.  It detected that the vehicle color has not been entered and forces the user to that input field.  The problem now is that NEXT FIELD does not trigger the AFTER FIELD of the current field in focus (probably for a good reason), but now we are ending up with a situation where even after the user enters the second field -- the program variable that represents the first field is never properly assigned because AFTER FIELD of the first field is never triggered. 

We realize that there are ways to brute-force to get around this issue (e.g. automatically parse the coded value in the ON CHANGE), but that would required a lot of code changes, in addition to the performance implication as well trying to validate on an "ON CHANGE". 

It would be nice if we somehow have an attribute on an action where we can force the interactive block to trigger the AFTER FIELD validation, similar to what we have with the VALIDATE attribute of an action -- but we don't.  So if anyone can think of an elegant way to solve this problem, please let us know.

[Sebastien F.]

Hello Huy,

Seems you are facing the typical 4GL/BDL input field checking issue, where you need to repeat the code in AFTER FIELD and AFTER INPUT (or in an ON ACTION in your case).

I don't think using ON CHANGE will help: For regular fields, ON CHANGE is like AFTER FIELD, except it's triggered only if the field value has changed.
But maybe I am confused by your explanation, you talk about BUTTONEDIT + COMPLETER ... so it's not very clear to me...
=> Please provide a little sample, it's always better than a long explanation!

I assume the [search] button is to run a query based on the values entered in the vehicle type and color, right?

I would suggest to use UNBUFFERED and move all the code checking field values in a function, that you can then call from different places in your INPUT dialog.

Note: It's easier to write a module dedicated to that input, to have the record definition at the module level, so it can be accessed from any function in the module. Think of a .4gl module like a class instantiated once...

I understand your request to have a way to call user-defined validation code for each field, and define this at a single point:
https://4js.com/support/issue/?id=FGL-02377#startissue

Seb

I am not using COMPLETER in this sample, it's just to illustrate the field input checking pattern:

Code

DEFINE rec RECORD
           v_type VARCHAR(30),
           v_color VARCHAR(30)
       END RECORD
 
MAIN
    OPTIONS INPUT WRAP
    OPEN FORM f1 FROM "form1"
    DISPLAY FORM f1
    INITIALIZE rec.* TO NULL
    CALL input()
END MAIN
 
FUNCTION input()
    INPUT BY NAME rec.*
          ATTRIBUTES(UNBUFFERED, WITHOUT DEFAULTS)
        AFTER FIELD v_type
           IF NOT check_values(DIALOG) THEN
              CONTINUE INPUT
           END IF
        ON ACTION search
           IF NOT check_values(DIALOG) THEN
              CONTINUE INPUT
           END IF
           MESSAGE SFMT("Search with %1 and %2",rec.v_type,rec.v_color)
    END INPUT
END FUNCTION
 
FUNCTION check_values(d ui.Dialog)
    IF rec.v_type NOT MATCHES "[CB]*" THEN
       ERROR "Type must start with C or B"
       CALL d.nextField("v_type")
       RETURN FALSE
    END IF
    IF rec.v_color IS NULL THEN
       ERROR "Must enter color to search"
       CALL d.nextField("v_color")
       RETURN FALSE
    END IF
    RETURN TRUE
END FUNCTION
 

Code

LAYOUT
GRID
{
Type:  [f1                         ]
Color: [f2                         ]
               [b1      ]
}
END
END
ATTRIBUTES
EDIT f1 = FORMONLY.v_type;
EDIT f2 = FORMONLY.v_color;
BUTTON b1 : search, TEXT="Search";
END
 

[Huy H.]

Thanks Sebastien.  I've provide the code below -- hope this will make it clearer of what we are trying to do.  It is import that the COMPLETER be part of this sample program -- as that was primary reason behind our current approach.

Code

TYPE vehicle_def  RECORD
         v_type    CHAR(1),
         v_license STRING,
         v_color   STRING
               END RECORD
 
DEFINE all_types DYNAMIC ARRAY OF STRING
DEFINE veh_rec   vehicle_def
 
MAIN
 
   DEFINE v_type  STRING
 
   OPTIONS INPUT WRAP
 
   LET all_types[1] = "BOAT"
   LET all_types[2] = "CAR"
   LET all_types[3] = "MOTORCYCLE"
   LET all_types[4] = "TRUCK"
 
   OPEN FORM f1 FROM "demo"
   DISPLAY FORM f1
 
   INPUT BY NAME v_type, veh_rec.v_license, veh_rec.v_color
   WITHOUT DEFAULTS ATTRIBUTES(UNBUFFERED)
 
     ON CHANGE v_type
       CALL set_completer(DIALOG, v_type)
 
     AFTER FIELD v_type
       IF valid_vehicle_type(v_type) THEN
         LET veh_rec.v_type = parse_vehicle_type(v_type)
       ELSE
         NEXT FIELD v_type
       END IF
 
     ON ACTION search
       IF LENGTH(veh_rec.v_license) = 0 THEN
         ERROR "license required"
         NEXT FIELD v_license
       END IF
       CALL search_vehicle()
 
     ON ACTION accept
       ACCEPT INPUT
 
     AFTER INPUT
       IF NOT validate_vehicle(DIALOG) THEN
         CONTINUE INPUT
       END IF
       CALL add_vehicle()
   END INPUT
 
END MAIN
 
FUNCTION set_completer(d, p)
  DEFINE d ui.Dialog,
         p STRING,
         items DYNAMIC ARRAY OF STRING,
         i INT
 
  IF p.getLength() > 0 THEN
    LET p = p, "*"
    FOR i = 1 TO all_types.getLength()
      IF all_types[i] MATCHES p THEN
        LET items[items.getLength()+1] = all_types[i]
      END IF
    END FOR
  END IF
  CALL d.setCompleterItems(items)
END FUNCTION
 
FUNCTION parse_vehicle_type(v_type STRING)
  IF LENGTH(v_type) > 0 THEN
    RETURN v_type.getCharAt(1)
  ELSE
    RETURN NULL
  END IF
END FUNCTION
 
FUNCTION valid_vehicle_type(v_type STRING)
  DEFINE t CHAR(1)
  IF LENGTH(v_type) > 0 THEN
    LET t = v_type.getCharAt(1)
    IF t MATCHES "[BCMT]" THEN
      RETURN TRUE
    ELSE
      ERROR "invalid vehicle type"
      RETURN FALSE
    END IF
  ELSE
    RETURN FALSE
  END IF
END FUNCTION
 
FUNCTION validate_vehicle(d ui.Dialog)
  IF LENGTH(veh_rec.v_type) = 0 THEN
    ERROR "vehicle type required"
    CALL d.nextField("v_type")
    RETURN FALSE
  END IF
  IF LENGTH(veh_rec.v_license) = 0 THEN
    ERROR "license required"
    CALL d.nextField("v_license")
    RETURN FALSE
  END IF
  RETURN TRUE
END FUNCTION
 
FUNCTION add_vehicle()
  DISPLAY SFMT("add_vehicle(): %1-%2-%3",
          veh_rec.v_type, veh_rec.v_license, veh_rec.v_color)
END FUNCTION
 
FUNCTION search_vehicle()
  DISPLAY SFMT("search_vehicle(): %1-%2-%3",
          veh_rec.v_type, veh_rec.v_license, veh_rec.v_color)
END FUNCTION
 
 
 

Code

LAYOUT
GRID
{
Type:    [f1         ]
License: [f2         ][b1    ]
Color:   [f3         ]
 
         [b2         ]
}
END
END
 
ATTRIBUTES
EDIT f1 = FORMONLY.v_type,UPSHIFT,COMPLETER;
EDIT f2 = FORMONLY.v_license,UPSHIFT;
EDIT f3 = FORMONLY.v_color,UPSHIFT;
BUTTON b1 : search, TEXT="Search";
BUTTON b2 : accept, TEXT="Add/Update";
END
 

If you run the provided sample program and enter CAR | ABC123 | RED, then click Add/Update, you will see all all three field values in veh_rec, in particular, veh_rec.v_type = "C".

Now if you type "CAR" in the vehicle type field, then click "Search", which will validate the License field and put the cursor on the empty license field, while bypassing the all important AFTER FIELD v_type block.  Because the AFTER FIELD block was bypassed, veh_rec.v_type never gets assigned.  If you continue and type "ABC123" in the license field, "RED" in the next field, then click Add/Update -- NOTE that veh_rec.v_type is NULL.

We know that a way around this is by putting the same block of AFTER FIELD code in the AFTER INPUT, but that is not ideal.  Creating a re-usable validation function is possible, but we will likely have to create a function for every single COMPLETER field -- as it cannot be generic.  We have MANY MANY forms that have MANY MANY completer fields.

[Sebastien F.]

Thanks for the sample, it clarifies your case.

First understand that this issue is not related to COMPLETER: You can remove the ON CHANGE v_type block, still the validation code in AFTER FIELD has to be executed when needed.

In fact the issue is related to the [Search] button: When the focus is in the v_type field, Genero cannot guess that the code in AFTER FIELD has to be executed when the user clicks on the button. By default the button action must be fired without changing the focus of v_type field: Any button / action can be related to all fields of your form... and the rule is to leave the focus in the current (v_type) field. Fortunately, we have the UNBUFFERED mode to get input buffer validated and copied into the variable, otherwise you would have to get the input buffer of the current field to check values (DIALOG.getFieldBuffer())

So a general validation callback function to be executed for a field would not help here: Anyway it would not be fired when you click on the [Search] button...

BTW I wonder why you are using COMPLETER everywhere in your forms, when a regular COMBOBOX could do the job and save you from writing additional verification code.
Is there a good reason why you don't use COMBOBOXes in this case?
Did you consider ITEMS=(("C","Car"), ("B","Boat"), ... ) ?

Another option could be to use a BUTTONEDIT instead of an EDIT for the v_license field, and attach the search action to it.
By doing this, if the user clicks on the BUTTONEDIT button, the AFTER FIELD v_type block is executed because the focus needs to go to v_license.
If the search function is related / specific to the v_license field, maybe that makes sense.

Try also to use

Code

ON ACTION search INFIELD v_license

and keep the [Search] button detached from the v_license field:
This will force the focus to be into v_license and force the AFTER FIELD to be executed before moving to v_license ...
Using Genero 3.10, check the difference with qualified and unqualified action view in form definition:

Code

BUTTON b1 : search, TEXT="Search";

and

Code

BUTTON b1 : v_license.search, TEXT="Search";

BTW pay attention with qualified action names on BUTTONEDIT, it has changed in latest 3.10 (FGL-4866):
http://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_Migrate_to_310_buttonedit_action.html

Otherwise, if [Search] is a not related to a particular field, the only option I see is to repeat the validation code in ON ACTION search (and AFTER INPUT)...

Seb

[Huy H.]

One of our developers found a work-around to handle this kind of situation where we need the AFTER FIELD to be executed while still continuing the input.  The way we solve this is by triggering the ACCEPT INPUT so that the AFTER FIELD validation of the current field would kick in.  Then within the AFTER INPUT block we force it back to CONTINUE INPUT.   

Code

ON ACTION search
  LET button_action = "search"
  ACCEPT INPUT
 
AFTER INPUT
  IF button_action = "search" THEN
    LET button_action = NULL
    { move original ON ACTION search block of code here }
    CONTINUE INPUT
  END IF
 
  { the usual AFTER INPUT codes }

 

[Reuben B.]

With your workaround, wouldn't you find also that any NOT NULL etc validation for ALL the fields in the dialog would be triggered?

With regards Seb's suggestion of UNBUFFERED, it will result in a reduction and simplification of code, and is what you would most likely use if starting from scratch.  To avoid operating in an environment that is a mix of buffered and unbuffered, and the two different coding styles required, it is something you should consider moving to in-between major versions of your product, and changing all of your dialogs to be unbuffered.  It is normally a case of adding ui.Dialog.setDefaultUnbuffered in an initialisation library call, setting validate="no" on certain actions (cancel, help etc) in the 4ad,  and reviewing code that uses the buffer to take account of the fact that the variable has now been populated.

With regards the population of 4gl variable and triggering of AFTER FIELD blocks on ON ACTION, what we are doing is no different to the Informix-4gl ON KEY behaviour.  Like you I found that frustrating and have in the past pushed for something like ... ON ACTION action-name VALIDATE=(NO|BUFFER|FIELD|ACCEPT|ALL) where ...
NONE is the current default buffered 4gl behaviour
BUFFER is the default unbuffered 4gl behaviour where the current field is populated with the value in the buffer
FIELD is as per buffer but also triggers the ON CHANGE, AFTER FIELD block for the current field to ensure that the value of the current field is valid.
ACCEPT is as per current ACCEPT behaviour where AFTER FIELD of current field is triggered and then the AFTER INPUT. 
ALL would trigger AFTER FIELD for every field in the dialog before the AFTER INPUT

At the moment we don't have equivalent for FIELD and ALL, and have to resort to repeatedly putting the calling of variable assigning from the buffer (if not using unbuffered), and validation functions into the ON ACTION.  I perhaps need to modify the concept to include VALIDATE(FIELD=[field1, field2, ...]) to consider the case where two or more fields are required to be valid before the ON ACTION is executed.  But for now if I had a case where I required multiple fields to be valid before triggering an action I would probably code ...

Code

INPUT ... ATTRIBUTES(UNBUFFERED)
 
AFTER FIELD field1
   CALL valid_field1() RETURNING ok, error_text
   IF NOT ok THEN
      ERROR error_text
      NEXT FIELD field1
   END IF
 
AFTER FIELD field2
   CALL valid_field2() RETURNING ok, error_text
   IF NOT ok THEN
      ERROR error_text
      NEXT FIELD field2
   END IF
 
ON ACTION action-name
  -- Ensure that field1 and field2 are valid before calling the action
  CALL valid_field1() RETURNING ok, error_text
   IF NOT ok THEN
      ERROR error_text
      NEXT FIELD field1
   END IF
  CALL valid_field2() RETURNING ok, error_text
   IF NOT ok THEN
      ERROR error_text
      NEXT FIELD field2
   END IF
   -- do the action

Reuben

[Reuben B.]

We are getting ourselves in a bit of a pickle with this issue.  Here's a bit of background.  Traditionally, we've been using BUTTONEDIT for our user to enter and store coded values.  For example, a vehicle type could be stored as "C" in the database to represent a car.  With the recent enhancement to Genero's COMPLETER attribute, we've made changes to our BUTTONEDIT widgets.  Now we display both the code and the translation in the input fields, and user can either enter "C" to in the field, or enter "Car" if they prefer the translation value.  Now our BUTTONEDIT content looks like this: [C - Car]

...

I will post separately to make replying easier, but I want to touch on this.  When COMPLETER attribute was implemented, a case was raised internally of how the COMPLETER copes as a BUTTONEDIT replacement.  That is the BUTTONEDIT is being used to enter a database code e.g. C, and allows the user to select from a list that would have C=Car, and would then display Car in a LABEL field to the right of the BUTTONEDIT e.g.

[C^] Car     (where ^ is the BUTTONEDIT button)


Now using COMPLETER the user rather than selecting from a list of C-Car etc, the user could simply type the code if they know it, or if they did not know it, they could type the description e.g. Car, and the completer would offer the code value C, and put that in the underlying 4gl variable.  That is seen in this example https://github.com/FourjsGenero/ex_autocomplete with the second field using airport codes.  The user can type in a City name e.g. Strasbourg and the 4gl variable is populated with the selected 3 letter airport code e.g. SXB. 

The code is not as clean as it should be, and when this was raised internally with our developers, they responded that that was not the expected usage of COMPLETER!!!! 

I would like the COMPLETER functionality enhanced to handle this case better, (ideally as simply as the COMBOBOX handles it with the one or two arguments for setItem).  So I would encourage anyone who has run into this, to make sure they have raised it here or with their support centre.

Reuben






 

[Huy H.]

For the record, we are using UNBUFFERED dialog in all our codes (just as in the sample provided).  Although, the problem I am describing is much like an unbuffered input -- reason being we have two variables to represent one field: veh_rec.v_type is the database field, and v_type is the variable that's tied to the input widget with completer attributes.  I know that the completer is not the issue here, but it provides a context of why we have two variables to represent the same field.

As for the completer usage, we are exclusively using it in BUTTONEDIT widgets with "zoom/lookup" functionality - (see attached image).  It might be a shock to your developers, but for us, where we came from where we use BUTTONEDITs to represent database codes, this was the most natural approach to extend the BUTTONEDIT functionality to make it more user friendly.  We gained a couple of things by doing this: 1) Both code and the translation is show to the user. 2) User can enter values using translation values, not just by codes.

You are spot on regarding the fact that the code is now a bit more complex with the BUTTONEDIT validations:

Code

      ON CHANGE approved_by
        CALL acu_officer_number_autocompleter(DIALOG, go_record.jurisdiction, 3, TODAY, FALSE)
 
      AFTER FIELD approved_by
        CALL acu_officer_number_autocompleter(DIALOG, go_record.jurisdiction, 3, TODAY, TRUE)
        LET completer.approved_by = acu_strip_code(completer.approved_by)
        IF valid_mj_code("officer_number",completer.approved_by,go_record.jurisdiction) = FALSE THEN
          NEXT FIELD approved_by
        END IF
        LET go_record.approved_by = completer.approved_by
        CALL go_load_completer_translations("approved_by")
 

There's quite a bit of things going on here:
1) We have to build the completer string that contains the code and the translation using go_load_completer_translations("approved_by")
2) Build an autocompleter function to suggest values, and possibly prefill if there's only a single match: acu_officer_number_autocompleter()
3) Parse the completer value to get back the database code: acu_strip_code()
4) Validate the parsed code: valid_mj_code() -- this was the only original function that was there prior to our implementation of the completer in for the BUTONEDIT

As you can see from above, we have to deal with synchronization of two variables: go_record.approved_by, and completer.approved_by.  A "combobox-like" implementation of the autocompleter would have probably saved us from this type of scenario.

As for the question of why not just use a combo box?  We have thought about that -- but in many situations, this is not ideal because it would required to fetch a lot of data from the database -- some of our BUTTONEDIT "zoom" selects from tables that can contain hundreds and thousands rows.

[Huy H.]

wrong attachment -- use this one instead.

[Enrico S.]

Hi All.
I have a similar problem but I was unable to find an elegant solution to this problem.
When the user chooses a value in the completer list the field buffer is not loaded, no trigger is fired and the focus stay on the current field.
A sort of AFTER COMPLETION trigger would be useful to be able to force the exit from the current field.

...
ON CHANGE myfield
    CALL fill_proposals (DIALOG, myfield)
...
AFTER COMPLETION
    case
       when infield (myfield)
          next field next - or some other statement
    ...
    end case

[Reuben B.]

Hi All.
I have a similar problem but I was unable to find an elegant solution to this problem.
When the user chooses a value in the completer list the field buffer is not loaded, no trigger is fired and the focus stay on the current field.
A sort of AFTER COMPLETION trigger would be useful to be able to force the exit from the current field.

...
ON CHANGE myfield
    CALL fill_proposals (DIALOG, myfield)
...
AFTER COMPLETION
    case
       when infield (myfield)
          next field next - or some other statement
    ...
    end case

I wonder if there is a potential solution using AUTONEXT http://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_FSFAttributes_AUTONEXT.html.

It looked promising applying the following changes to my test program
- add AUTONEXT as attribute for form field entry
- changed field from STRING to an arbitrarily large CHAR e.g. CHAR(50)
- when filling the proposals, pad out with spaces to so that each entry in the list is the length of the CHAR e.g pad with spaces so length is 50
i.e selecting an entry fills out the EDIT field and thus AUTONEXT occured to move focus to next field

Now question for us is at our end, should we require the last two steps or should this be possible with a STRING. ie if AUTONEXT is used with COMPLETER attribute, should that move focus to the next field when user selects an item?  It would seem sensible too, but is there something I might have overlooked.

Reuben

Reuben

[Enrico S.]

Hi, Reuben.
Thanks, I have applied what you suggest.
Unfortunately it works only using the keyboard to choose a row in selection list; not working in case of click on the selection list (the focus stay on the search item), so it cannot fully work around the problem.

Furthermore filling item with trailing spaces looks like a vintage programming style and can have an impact to the field validation if the input cell in form is not large enougth to contain a so filled value.

In my opinion this case need a specific solution to avoid such workaround. This could improve the completer.

Talking about the question at your side, in my opinion the programmer should be able to set the behavior (stay on the field or jump to next field after completion) and to use both char() and string fields.

Best regards.
Enrico

[Reuben B.]

Hi, Reuben.
Thanks, I have applied what you suggest.
Unfortunately it works only using the keyboard to choose a row in selection list; not working in case of click on the selection list (the focus stay on the search item), so it cannot fully work around the problem.

My example was moving onto next field with mouse-click with GDC, not sure what is different with your example.   However I do note that when I try my example with GBC it doesn't.  Something for me to report

Furthermore filling item with trailing spaces looks like a vintage programming style and can have an impact to the field validation if the input cell in form is not large enougth to contain a so filled value.

In my opinion this case need a specific solution to avoid such workaround. This could improve the completer.

Talking about the question at your side, in my opinion the programmer should be able to set the behavior (stay on the field or jump to next field after completion) and to use both char() and string fields.

I'm not going to disagree about vintage style comment.  One of the nice things about using STRING over CHAR (and same applies DYNAMIC ARRAY over STATIC ARRAY) is not having to worry about picking an arbitrarily large number as the maximum length. 

This behaviour is more a reflection of what AUTONEXT does, that is when a field is full, move onto the next field ie 10 character account code, user keys in 10 characters and focus moves to next field without requiring TAB.  Similarly when using AUTONEXT with a DATEEDIT field, if the formfield has 10 characters it works because selecting date has filled the 10 characters (assuming dd/mm/yyyy).  If the formfield has 12 character, focus won't move to next field.  Hence the trick of padding with spaces to fill the field so AUTONEXT occurs.

It maybe that rather than re-using AUTONEXT,the better long-term solution is for a new keyword or .4st that can be used by DATEEDIT, COMBOBOX, EDIT+COMPLETER and other widgets where final selection is with press of a mouse to signal a move onto next field.  Unfortunately for you, you have raised this topic right on the cusp of a release.

Reuben

[Reuben B.]

I tried to apply my AUTONEXT technique to https://github.com/FourjsGenero/ex_autocomplete but I hit another issue in that using keyboard to scroll down list of entries in completer list would also trigger AUTONEXT .  There maybe a workaround but I'll leave it there for the moment and let developers discuss when they have finished wrapping up 3.20

[Leo S.]

Loud thinking: If the clients would send ON CHANGE again when the completion was chosen (in other words, flush the field) the 4GL programmer could easily detect the completed case and invoke a NEXT FIELD.
Also for Huy's case the way to invoke AFTER FIELD with the help of ACCEPT INPUT wouldn't be needed.
Existing code will invoke setCompleterItems again with the one and only item already in the field : the client could suppress showing the list in this case (checked with GDC: its the case).
It will be discussed internally and we will come back to this issue.

For the completer discussions:
Sure it would be desirable to have a "translating" completer, meaning the 'C' code is in the INPUT and not the completed text (CAR).
But as far as I understand Huy's comments *both* the code and the completed text are wanted to be visible , so its not an INPUT from just 1 field (if both are wanted we would need to implement a way to express in which field the code has to be displayed)
In any case if you feel a build-in translating completer option (as Huy wrote: A "combobox-like" implementation of the autocompleter) could save you a lot of code, feel free to send in  a feature request via the support centers and illustrate some code samples how you think it should work.

Regards, Leo