BDL menu handling - accept key

[Trevor W.]

We have a piece of code thus:

FUNCTION f_3opt(f_3_n1,f_3_o1,f_3_c1,f_3_n2,f_3_o2,f_3_c2,f_3_n3,f_3_o3,f_3_c3)
DEFINE
    f_3_n1,f_3_n2,f_3_n3 CHAR(35),
    f_3_o1,f_3_o2,f_3_o3 CHAR(1),
    f_3_c1,f_3_c2,f_3_c3 CHAR(19),
    f_ans CHAR(1)
LET f_ans=NULL
MENU f_ans
ATTRIBUTE(STYLE="dialog",COMMENT="Please choose",IMAGE="question")
COMMAND f_3_n1 f_3_c1
    LET f_ans=f_3_o1
    EXIT MENU
COMMAND f_3_n2 f_3_c2
    LET f_ans=f_3_o2
    EXIT MENU
COMMAND f_3_n3 f_3_c3
    LET f_ans=f_3_o3
    EXIT MENU
END MENU
RETURN f_ans
END FUNCTION

Whilst this works in most conditions, if the function is called like this:
...
CALL f_3opt('Change','C','Change the entry','Accept','A','Accept the Entry','Quit','Q','Quit') RETURNING l_onecharvar
...
Then we get the result that if the keyboard is used to select the item and the <Return> or <Enter> key is used, the Accept option is ALWAYS triggered (obviously).

Would an extra ON ACTION accept ...  clause in the menu trap the Accept key, and if so how would we detect the 'selected' item from the menu ?
Would the DIALOG.getfieldtouched() method do the trick?

For the moment I have amended the application to rename these menu options.

Thanks for any advice.

[Reuben B.]

Trevor,

Try this ...

f_3opt('&Change','C','Change the entry','&Accept','A','Accept the Entry','&Quit','Q','Quit')

... obviously you don't want to change all your calls to this function, but you can note the effect and perhaps add a call inside the function to prefix the desired single letter accelerator with &.  The effect being that the action is no longer "accept" but "&accept" and hence doesn't pick up the accelerators for the accept action.

However a note of caution, the documentation says ... https://4js.com/online_documentation/fjs-fgl-manual-html/User/Menus.html#COMMAND

With the COMMAND clause, if the user includes an ampersand (&) in the option text, the system transforms it as an accelerator for the next character. The ampersand is not considered when determining the name of the action. For example:

... however from my tests it does look like the ampersand forms part of the action name.


If you are prepared to rip out the internals of your library function and want to get to a point where you don't have a f_2opt, f_opt3, f_opt4, f_opt5, ... series of functions with lots of duplicated code, you could go down the path of one MENU statement that uses ON ACTION with a set of generic names (action1, action2 etc), and use AUI Tree manipulation to set the text and comment attributes and hide the actions.  I have an example of that as part of my auitree example on sourcefourjs but I should really break it out into a standalone example.

Reuben

[Trevor W.]

Thanks Reuben,

I'll take a look at the example and play around with my code.

[Sebastien F.]

Hi all,

Reuben is right regarding the documentation content, it appears that it does not reflect the reality:
  COMMAND "T&est"
Creates and action with the name "t&est", not "test", as described in the doc.
We will review this, I don't know how this mistake occurred.

Sorry for that and thanks.
Seb

[Sebastien F.]

Trevor,

From a end-user / ergonomics point of view:

It appears that you want to implement a user choice, that is dynamically configurable in programs, with variable number of options and variable option names...
Did you consider to use another solution as a MENU for this or has it to be a MENU decoration?

Typically, you could open a window with a form that shows a RADIOGROUP, let the end user select one of the radio options, and just have regular OK / Cancel buttons...

Yes, one additional click for the user... but I am just wondering what is the standard GUI in such case?

Yes, we are missing a ui.RadioGroup built-in class to manipulate the radiogroup items by program like you can do with the COMBOBOXes, but still it can be done my manipulating the AUI tree.

Sounds to me a bit more elegant to me as a traditional MENU...

What does your MENU look like when you have long option names?

  [Accept last commit]  [Transfer files automatically]  [Give a chance to radiogroup]  [Cancel]

?

If the list of choices is large, consider using a TABLE with check boxes?

Seb

[Trevor W.]

Hi Seb,

I've been using Genero for less than 18 months, so we are talking about legacy 4GL code.

Many years ago, I realised that 90-95% of the 'pop-up' menus in our application(s) were either a two or three option. So I implemented 'generic' 2 or 3 option menu functions, to stop hard-coding them and introduce a little flexibility in the code.

It was with the transition to Genero, that the problem with the 'Accept' action and menu option became apparent. Being a new Genero person, I didn't make the connection until a user reported the unexpected behaviour - different to the original code.

Yes, these functions will need to be re-written (over time) and I was looking for some ideas from more experienced programmers. But I don't want to give my users too much of a shock with new widgets, or remove the functionality of keyboard input. At least not yet!!

The past 12 months have been more about keeping the business logic intact, than introducing new stuff. As I (we) learn more about Genero, then we will move forward and re-write.

Trevor

[Reuben B.]

Many years ago, I realised that 90-95% of the 'pop-up' menus in our application(s) were either a two or three option. So I implemented 'generic' 2 or 3 option menu functions, to stop hard-coding them and introduce a little flexibility in the code.

Can I just say well done for doing that.

An interesting code test is to do something like ...

grep -i "menu.*style.*dialog" *4gl | wc -l

IMHO, a good result for this is 10 or less.

If I look at the code base where I used to work before I joined FourJs Asia Pac, our generic menu function has over 1500 calls to it.  So instead of 1500+ MENU STYLE="dialog", there are 2.

Reuben