next »

[Sebastien F.]

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

[.]

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

[Sebastien F.]

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

[.]

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.

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.

Code

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

Code

<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.

[.]

-----------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

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.

[.]

Personally, I think Jeff's got this right. It not only covers how to configure your own context menu

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.