next »

[Judy S.]

Has anyone found a solution for this:

We had the following in our default.4ad file:
<ActionDefault name="prevfield" acceleratorName="up" acceleratorName2="left"/>
We defined it this way in order to allow the cursor to jump to the previous input field when the user presses the left arrow key, or presses the up arrow key, to achieve the same behaviour that the BDS GUI and BDS character versions provide.
 
However, we found that if the user is editing a text field that is for example 10 characters in length, and the cursor is at the 10th leftmost character, and the user wants to move back to change the 9th character, if they press the left arrow key, the cursor jumps to the previous field. This is not the intention of the user. It should only jump to the previous field when the left arrow key is pressed if the cursor is at the start of the form field (of any other data editable type), the same way it does for all predecessor run-time versions.
 
We ended up removing the "left" accelerator name from the "prevfield" action, to allow leftward movement within a field while the user is editing that field, however, now when the user reached the start (left-most) character of that field, when they press the left arrow, it will not move to the prior input field.
How can we get the behaviour of the left key to be the same as it was in BDS? i.e. left arrow will move the cursor 1 character to the left until it reaches the left-most character, and then it will move to the previous input field?
Note I had reported this issue in 2005, and it received Request #GDC0304, however, I just found out it has not been implemented and there is no date set to do so. That is why I would like to know if anyone has come up with a workaround solution.

Thanks.

[Reuben B.]

When I was a customer, one of my very first posts to the mailing list that preceeded this forum was very similar, I was trying to use up/down to move between fields.  The answer I got back in 2002 is still appropriate today, that is Genero will attempt to use the default behaviour of the front-end you are on.  The appropriate key(s) for the front-ends we use is Tab and Shift-Tab, not up/down/left/right. 

If you have a end-user or developer challenge you on this, get them to look at a system program that has multiple field entry, I used to use Control Panel->ODBC Settings on Windows,  but nowadays I find a better worldwide example is to get them to do the following.  Goto facebook.com and sign out of your account.  You then get taken to a screen that allows you to Sign Up to Facebook.  It has a number of fields, firstname, lastname, password, mobile number, birthdate.  Now note what keys you can use to move between these fields, the answer is Tab and Shift+Tab, not up/down/left/right.

Having said that, it is possible to get close to what you want, however I would very much encourage you to respect the natural default behaviour of the front-end.

In your .4st add the following ...

Code

<Style name="*">
    <StyleAttribute name="localAccelerators" value="no"/>
 </Style>

In your .4ad add the following ...

Code

  <ActionDefault name="left" acceleratorName="Left" defaultView="no" contextMenu="no"/>
  <ActionDefault name="right" acceleratorName="Right" defaultView="no" contextMenu="no"/>

In your .4gl add to every dialog ...

Code

        ON ACTION left
            IF FGL_DIALOG_GETCURSOR() > 1 THEN
                CALL FGL_DIALOG_SETCURSOR(FGL_DIALOG_GETCURSOR()-1)
            ELSE
                NEXT FIELD PREVIOUS
            END IF
        ON ACTION right
            IF FGL_DIALOG_GETCURSOR() <= (LENGTH(FGL_DIALOG_GETBUFFER())) THEN
                CALL FGL_DIALOG_SETCURSOR(FGL_DIALOG_GETCURSOR()+1)
            ELSE
                NEXT FIELD NEXT
            END IF

That will do what you want for case when widgets=Edit, behaviour may vary when focus is on widgets that don't allow text input and may require additional logic.

The key for that is using the localAccelerators style attribute that was added way back in 2.10 which controls where an accelerator key is defined in a .4ad, and has use with a particular widget, what gets priority, the 4gl action or the widgets behaviour.  So in the above example, the left and right keys trigger the 4gl action, rather than the widget behaviour to move left/right one position.

Whilst I would not recommend you use it for the case above, being aware of and using that presentation style may be applicable elsewhere.

Reuben

[Judy S.]

Hi Reuben,

Thank you for your detailed reply. However, since this would require coding in the .4gl module, which would mean every place would need to have this code added to all "input" dialogs, I will just leave it the way it is. I modified our global action defaults file (default.4ad) to define shift+left arrow key and also Control+left arrow key will behave the same as the Shift+tab key. So now the user has several choices to moving backward to a previous input field - mouse click into the prior field, Shift+tab, Shift+left, or Control+left. So far I think the customer is willing to accept this.

Thanks again for your suggestion!