next »

[David Z.]

I am converting my software from I4GL to 4js. In I4GL I used F12 as my accept key and Enter did the same as TAB (next field). My users can't get the hang of Enter being the accept key. An easy fix. Move the acceleratorName of Enter and Return from ActionDefault accept to nextfield, and use F12 as the acceleratorName for accept in the 4ad file.

With OPTIONS INPUT NOWRAP... When in a single CONSTRUCT statement, Enter acts like TAB until the last field where it accepts the input, builds the where_part and exits.

I have a DIALOG with five multi-field CONSTRUCT statements. I use OPTIONS INPUT WRAP so the user can tab and mouse around all five CONSTRUCTS so it looks like a single CONSTRUCT to the user. Enter behaves like TAB because of the 4ad file. Is there a way to have Enter be the accept key and trigger "ON ACTION accept" when it is used on the last field of each CONSTRUCT, but continue to act like TAB on the other fields? Or asked another way...Is there a way to have each CONSTRUCT, in this DIALOG, to act as a single CONSTRUCT on the last field? Keeping in mind, TAB still needs to wrap from CONSTRUCT to CONSTRUCT.

I've tried several things like loading a special 4ad file in a "before last_field" that redefined Enter as the accept key. But you can't load a 4ad file in the middle of a dialog. Putting OPTIONS INPUT WRAP in "before last_field" doesn't work either.

I need to keep the five separate CONSTRUCT statements because I need to search different tables depending on which CONSTRUCT they use.

I have a messy workaround where, in my per file, I define...
  action nextfield  ( accelerator=Tab )
  action returnenter ( accelerator=Return, accelerator2=Enter )
In my 4gl file, in "ON ACTION returnenter", I have INFILED checks to see if I am on the last field of a CONSTRUCT and wrap up the DIALOG.

Any better ideas?

Thanks for your help.

[.]

I'm not in the office so can't try but I would set options input wrap, unbuffered input, don't set enter as accelerator for accept but perhaps for some other action, eg enter_key then have

ON ACTION enter_key
   IF INFIELD(lastfieldname)
   THEN
        ACCEPT DIALOG
   ELSE
        NEXT FIELD NEXT
   END IF

hope this helps

Jeff

[David Z.]

Your idea is the same as mine. That is what I'm doing. Where you have the ACCEPT DIALOG, it does not trigger the ON ACTION ACCEPT block where I do all my field edits and checks, plus, ACCEPT DIALOG does not trigger my AFTER FIELD clauses in the CONSTRUCT. It only does that if called from the ON ACTION ACCEPT block.

David

[.]

Hi David,

This should be no problem.

Change FROM

    ON ACTION ACCEPT
        all your verification

TO

    ON ACTION ACCEPT
          ACCEPT DIALOG

    AFTER DIALOG
         all your verification

(you probably won't need the ON ACTION ACCEPT as I think that should fire anyway)

As for your AFTER FIELDS - I would have thought that the NEXT FIELD NEXT should fire these - if they don't then obviously that is a problem. ACCEPT DIALOG might not fire them but you only do that on your last field so you could simply place a copy of the after field verification for that within the IF INFIELD THEN statement for that field.

Hope this is a help. If NEXT FIELD NEXT doesn't fire the AFTER FIELDS then thats more of a problem and if you are in a position to test and verify it doesn't I'll try and think of another option though it might be on Tuesday now.

Thanks

Jeff