Four Js Development Tools Forum

I have logged through UK support (thank you Neil) a change to right click behaviour within Genero. At present right click cannot be trapped and always shows EVERY action, plus cut & paste, next/previous field/row etc.

For applications I find that much of this is inapproriate for the user and also fails to allow for 'context sensitive' right click menus specific to the exact field or row that are currently in. Due to the use of pre-processor files loading in many 'standard' actions into our programs this can also leave us with over 100 actions listing on a right click, hardly usefull. I would like to take a far more 'windows' approach by only presenting the options that are appropriate. Infact, with the way it currently works 'nothing' would often be a better option.

I feel it would be usefull to gauge just how helpful a change would be to everyone else out there

There have been three things requested

1) A Setting somewhere to disable completely the automatic rightclick feature
(The NO rightclick would be better than everything approach). Probably not required if other features implemented?
 
2) New Action Default option,  rightclickView<yes/no> - default = yes = if 'no' then that action does not appear on the rightclick menu.
 
3) New Action Default option, accelerater="rightclick" = if the dialog has that action then the default rightclick menu is NOT drawn and the action will be triggered.

Please respond if you would benefit from any of these changes, or any alternative ways you feel might work better. I find this a big problem but it might just be me?

Thanks

Jeff

This is not a problem for us .................. at the moment.
We have implemented Genero in a way that has few action defaults so the list produced by right-click is not too large.
In some ways it is proving quite useful - we have a 'standard' toolbar which never changes, inactive actions just appear greyed out (this is so that the toolbar is not constantly expanding and shrinking) and using the right click just gives us a nice concise list of what actions are available at any point in time.

Given the three proposals you have suggested I would think that the 2nd one (option on ActionDefault to dictate whether it will appear on right click) would be the only one useful to us, unless of course we totally chnage the way we have implemented Genero!

Martin

Are you aware that if the text attribute of the actiondefault is "" then the item won't appear in the right click menu.  Our pre-processor loads up 36 actions corresponding to the user pressing A-Z, 0-9 whilst in a DISPLAY ARRAY.  These actions don't appear in the right click menu as the text attribute is "".

Also the right-click options list all the actions that are active at that point in time.  Although it may not be practical, only set the action active when it is really active e.g.  instead of ...

ON ACTION action
   IF FGL_DIALOG_GETFIELDNAME()="fieldname" THEN
      # do something only if in fieldname
   ELSE
      # ignore
   END IF

... do ...

BEFORE FIELD fieldname
   CALL DIALOG.setActionActive(action, TRUE)

AFTER FIELD fieldname
   CALL DIALOG.setActionActive(action, FALSE)

ON ACTION action
   # do something

... I'd rather code something like ...

ON ACTION action (ACTIVEFIELDLIST="fieldname")
   # do something

... but thats another story.



We find it beneficial to have all the active actions listed there, because we can say to a user if you want to know what you can do at any point in time, just right-click.  (or press shift-F10), (and yes in some instances it is more than a screen height in length and wraps to a second column and I do wonder if actions such as Help->About really ought to appear but it tells them what they can do)  What I'd like to change but it is a very low priority is the order the items appear, and the fact that keyboard accelerators appear with a + when in the .4ad they are defined with a - (we have an option to append the accelerator to the text and/or comment attribute)

Of your suggestions, option 2 would be the most practical, however instead of yes/no, how about a rightClickIndex attribute similar to tabIndex that helps determine the order the items appear in the right click menu.  A value of 0 would indicate that it shouldn't appear, and if not specified the value would have a default value of 1.

Jeff --> It seems to me that Neil has already transmitted your three requests to the Four J's Support ;-)

As a general idea, this corresponds to a feature request which has already been referenced.
#fz.#955 => Configure right click contextual menu

This feature request has already been the object of some discussions, but at this time, is still not planned to be implemented.

I'll add your name to the list of requesters.
 

Yes,  I requested the feature on behalf of Jeff.
I also suggested posting here to get feedback from other developers ( and to 'get the ball rolling' on the forum! ).

I like the feature of MENU (STYLE="popup") this gives you a way to generate a 'right-click' style context menu. The only problem is the most obvious way to trigger that type of code would be on a right click, but you can't because of the automatic right click menu.

e.g:
ON ACTION rightclick

This is very much the way I would prefer to work. I can't have lots of actions with a text of "" because of toolbar items as well as buttons spread around the screen where I would like to use right click as context sensitive. Pretty much all the actions are available at any given time but not relevant to what the user is doing most of the time.

I think this is particually complicated for us because we use some very large and complicated forms, probably more so than most (ask Neil!) - so a user might be doing a sight test (it's an optician system) but has the option to change the dates that the calendar page is showing but is unlikely to actually use that action at that point - therefore not needed in a right click but they don't want the action disabled.

Please: An ON ACTION rightclick would work very well for us

Actually, there are two main orientations we could provide:
- one is following the "ON ACTION contextMenu" (or whatever the name is), which allows you to create your popup menu how you would like
- the other is to have a description of the contextmenu somewhere (form, contextmenu file) and bind the context menu to the field.

On a GDC point of view, the first solution is probably the easiest solution. But:
- on a web based application, this is likely to be a nightmare as you'll have to wait for the network roundtrip to display the context menu - and I don't talk about http over SSL + authentication based applications.
- I would prefer an higher level solution.

Some ideas we've in mind for the solution 2):
let you define

<ContextMenuList>
 <ContextMenu name="foo">
  <ContextMenuCommand/>
  <ContextMenuGroup>...</ContextMenuGroup>
  <ContextMenuSeparator>
 </ContextMenu>
 <ContextMenu>...</ContextMenu>
</ContextMenuList>
 

and in the form item definition

EDIT xxx = xxx, contextMenu="foo";

Then you can define your contextmenu here.

In addition, there is the idea of PlaceHolders, which could consists in:
- the system context menu (copy/cut/past/select All, depending on the widget you're in)
- the CopyField... actions if you're using it
- the default context menu as we're doing today, to let your applications be compatible
- a list of actions you can define on the 4GL side, to have a real contextual context menu

Just putting some ideas here, your feedback is welcome.

Pierre-Nicolas

Hi Pierre-Nicolas, Thanks for the response. I think the first one would best suit my needs, but understand your need to cover all types of implementation. The biggest issue I see with the contextmenu is you cannot readily change the options based upon the context of data (overall data rather than a single field) or to be completely dynamic. For instance: If you had a list of products right click could show a list of accessories for that item - this would have to be dynamic. As long as this could be got around by manipulating the dom-tree in a before field then it could be fine but would this cause a problem on web-based applications?

I support Neil 100%.

I'd like to be able to trap the rightclick event.

Best regards,
-Snorri

With this solution we get closer to a "click-event-based" programming, while 4gl is supposed to be abstract.

For this reason I don't like it very much.

Seb

Note that the "dynamic" solution based on MENU ATTRIBUTES(STYLE="popup") would not be fully dynamic: Today it is not possible to build a MENU dynamically: All options / action handles must be declared with COMMAND or ON ACTION. Using variables are COMMAND option names is very tricky to implement for us, and not supported with the new code handling multiple dialogs in 2.10. We rather want to provide something like a DIALOG.addAction() method to build the dialog.

Hi Seb,

The idea here is merely to allow an action 'rightclick' which is entirely consistent with doubleclick action in tables. I see it merely as action based in line with everything else as we still need to trap the rightclick using an ON ACTION command.

What we do with it then is entirely up to us. In Neils example, and the one I would use most often I would have
MENU "" ATTRIBUTES(STYLE="popup")


END MENU

Hi Seb,

Thanks for your feedback, although I think we may have interpreted this differently. I see this working very like doubleclick does in tables, only for rightclicks. We assign an action to rightclick which must then be trapped using ON ACTION righclickaction. What we then do with it is up to us as programmers, most probably using a menu though. You are right to say that menu's aren't truly dynamic but then we don't really need them to be.

An example might be:

ON ACTION myrightclickaction

-----------SORRY, ABOVE REPLY WAS INCOMPLETE WHEN I ACCIDENTLY POSTED IT-----------
-----------I CAN'T FIND WHERE I CAN EDIT THAT POST SO HAD TO POST THIS NEW ONE-----
Hi Seb,

Thanks for your feedback, although I think we may have interpreted this differently. I see this working very like doubleclick does in tables, only for rightclicks. This would remain abstract I feel. We assign an action to rightclick which must then be trapped using ON ACTION righclickaction. What we then do with it is up to us as programmers, most probably using a menu though. You are right to say that menu's aren't truly dynamic but then we don't really need them to be.

An example might be:

ON ACTION myrightclickaction

    CALL my_right_click_menu() RETURNING lv_action


FUNCTION my_right_click_menu()


    DEFINE lv_loop                   SMALLINT
    DEFINE lv_action                STRING

    MENU "" ATTRIBUTES (STYLE="popup")
         BEFORE MENU
                -- Hide unused options
               FOR lv_loop = (lv_options + 1 ) TO 100
                     HIDE COMMAND la_options[lv_loop].command_name
               END FOR

         ON ACTION la_options[1].command_name
               LET lv_action = la_options[1].command_action

         ON ACTION la_options[2].command_name
               LET lv_action = la_options[2].command_action

         ...... etc ........

    END MENU

    RETURN lv_action

END FUNCTION
-----------------------------------------------------------------------------------------

Hope that this helps.

Thanks

Jeff

I agree that right click is a problem to some people.
Any program with a 20 or more actions current in a dialog meas you get a very large and not very nice context menu.

I'd suggest something simple like a Window style attribute of:
rightClickMenu - yes(default) / no

This is a enough to make some people happy that just don't like the large context menu of programs with lots of actions.

Then you can allow rightClick as an accelerator.
 <ActionDefault name="myrightclick"  acceleratorName="rightclick" />

This accelerator ONLY works on Windows with a style that turns off the default rightClickMenu.

Sorry Neil but we should not mix different concepts.
An accelerator is a keyboard combination, not a mouse event.

However, the Window style attribute "rightClickMenu" makes sense to me... I will add this idea to the spec.

Seb

Seb,

So if rightClickMenu="no", how would the developer trigger an action based on the user right-clicking?

Also if we end up writing code to respond to the likes of right-click (and perhaps left-click, double-click, mouse-down, mouse-up, hover as well) we would need to identify where or over which widget the mouse is.

Also don't forget that shift-F10 does the same as right-click so rightClickMenu might not be the best word.

Reuben

Good point Reuben.

I am convinced we don't go in the right direction when you start to see "rightClick" events in the 4gl code.

Actually the Window style attribute we talk about should just avoid the default context menu.

So maybe "defaultContextMenu" is a better name...

Seb

Why not?

Isn't a mouse click the equivalent of a function-key.  Its just that the "function-key" is handily positioned at the top of the mouse underneath your fingertips.  Through left, right, double click, mouse down, mouse up etc you have more than 1 "function-key"

However what you do get with a mouse button event is some indication of position.  Whereas a normal function-key press you can associate with what the current field is, the mouse-click will typically be associated with the current position of the mouse, or whatever widget the mouse cursor is currently positioned over.

I don't think this type of code removes the abstraction...

e.g.

   ON ACTION mycontextmenu
      CALL mycontextmenu(FGL_DIALOG_GET_MOUSE_CURSOR_WIDGET_TYPE(), 
                                       FGL_DIALOG_GET_MOUSE_CURSOR_WIDGET_NAME())

<ActionDefault 
   name="mycontextmenu" 
   acceleratorName="Right-Click" 
   acceleratorName2="Shift-F10" />
 
 

Other mouse actions we are similarly limited in, include the ability to identify what field a user double-clicked on in array, we can tell the row, but not the column.  Also within canvas the user can't interact with the canvas using the mouse at all because we can't tie an event to a mouse click, or identify the cursor position within the canvas.

Personally, I think Jeff's got this right.  It not only covers how to configure your own context menu, and coupled with his first post 

"1) A Setting somewhere to disable completely the automatic rightclick feature
(The NO rightclick would be better than everything approach). Probably not required if other features implemented?"

it solves all of the complaints we've been having amongst our development teams and end users requests.

This is certainly the approach that would work best for me although there is the issue of multiple dialogs so we would need rightclick to select a field/row as per a left click so that getCurrentItem() can be used, as well as any before field actions to help identify where we are.

Also, warning to anyone wanting to use that code as a context menu template as it's wrong! To get it working like that you would need to use 'COMMAND' instead of ON ACTION and command_name must be unique (I use ' "_", lv_loop USING "<<<<" ' for unused blank ones I want to hide). Alternatively you can use ON ACTION (again, all unique and none blank) but call DIALOG.setActionHidden). This allows you to also set text and images by manipulating the dom tree. I can be emailed on jeff.mcfee@eyesiteonline.co.uk if needed.