next »

[.]

Hi,

Could you please consider adding NEXT FIELD FIRST and NEXT FIELD LAST as new features please.

I personally would find this very usefull dealing with multiple dialog's with common included sections of code.

This would make maintenance much easier for us when changing specific areas of the system without affecting other parts that include the same included file.

Thanks

Jeff McFee

[Sebastien F.]

Jeff,

Could you please give us more details about you expectations?

Especially in multiple dialogs, what means FIRST and LAST to you?
I guess it's the first and last field of the current sub-dialog?

Of course it would use the tabbing order if FIELD ORDER FORM is used.

Seb

[.]

Hi Seb,

Thanks for the response.

I assume by sub dialog you mean something like an individual INPUT statement within a Multiple Dialog?

If so, I actually want it to go to the first or last field of the whole dialog rather than just the sub dialog. This means that where I code seperate sub-dialog into files that are included, they don't need information about the whole dialog but can instead rely on NEXT FIELD FIRST/LAST to get to the start or end of the whole dialog.

I agree that the tabbing order should be used if FIELD ORDER FORM is used as this better fits the Genero model.

Thanks

Jeff

[Sebastien F.]

Thanks for the details Jeff.

I am sure others will ask for first/last field of current sub-dialog...

That will end up to something like:

  NEXT FIELD [DIALOG] FIRST
  NEXT FIELD [DIALOG] LAST

Maybe now you scan the form definition and search for the first/last field in the AUI tree and then use:

  DIALOG.nextfield("fieldname")
  CONTINUE DIALOG

Seb

[.]

Hi Seb,

More than happy to have the NEXT FIELD [DIALOG] FIRST/LAST - as much flexibility as possible.

Thanks for that AUI tree advice - not sure how I would identify the active items in my form though. The form I most need this on is nearly 5000 lines (.per), so quite a few fields and most of which won't be active. Is there a way of identifying only those in the current dialog?

Thanks

Jeff

[Sebastien F.]

You have FormField.active, TableColumn.active... and the "name" attribute gives the field name,

Don't use DialogInfo this may be removed in future versions.

Of course if we change the AUI structure you must be ready to change your code.

Seb

[Reuben B.]

Seb:

There should be entry in the feature requests database somewhere for this request.  I recall thinking we'd have a similar need during the Genero migration in my previous job.

The two concerns we had at the time were ...

1) A user could drag and drop the columns into a different order (or hide the columns) in an INPUT ARRAY.  There may have been a NEXT FIELD fieldname to move the cursor back to the first column but the columns could have been rearranged such that the first column was no longer the first column.

2) I was aiming to get to a point of having customers customize their .per file but having 1 .4gl to support all customers.  Again this could mean a customer could rearrange the .per so that the fields were in a different order and/or hidden, and then an explicit NEXT FIELD fieldname to the first field in a form should really be a NEXT FIELD FIRST

Didn't really push the issue as the first fields tended to be the key fields and they don't tend to get moved or hidden, and any NEXT FIELD to the first field didn't occur that much.   About the only situation I can think of now is where you had a composite key and if when adding a record the composite key already existed you would want to move the cursor to the first field of the composite key. 

Jeff:

The difficulty for a method for you to use now is determining what the first field is.  Unfortunately DIALOG.getCurrentItem() returns NULL in BEFORE INPUT.

A quick play suggested this technique (using some functions you are aware of) may have potential to determine the first field in a dialog...

CALL fgl_bind("my_fgl_bind")  -- call before a dialog where you intend to call my_next_field_first()

-- Record the current field (i.e the first) and then turn off fgl_bind
FUNCTION my_fgl_bind(e)
DEFINE e om.DomNode
DEFINE d ui.Dialog
   LET d= ui.Dialog.getCurrent()
   LET m_first_field = d.getCurrentItem()
   CALL fgl_bind("")
END FUNCTION

-- equivalent of NEXT FIELD FIRST
FUNCTION my_next_field_first(d)
DEFINE d ui.dialog
   CALL d.nextfield(m_first_field)
END FUNCTION

[.]

Just a small reminder about fgl_bind: this is an undocumented, nearly untested and unsupported feature, which may be changed, replaced or removed. Moreover, you may generate an AUI tree which may be invalid from a front-end point of view, which may lead in best case to weird effects and to GDC crash in the worse case ; these front-end issues will not be considered as a blocking /critical issues, so use it very carefully.

[Sebastien F.]

Reuben,

1) I second Pierre-Nicolas about fgl_bind().

2) I have filed a new request in bugzilla for NEXT FIELD FIRST/LAST: bug id = 14858, and will have a look at this.

Seb

[Sebastien F.]

Ok, I started to look if NEXT FIELD FIRST / LAST could be supported.

Basically it's not a big deal to extend the syntax and support FIRST/LAST keywords, but we must clearly specify what these do.
Actually FIRST/LAST would be part of the so called "abstract" field specifications for NEXT FIELD, like PREVIOUS, NEXT and CURRENT.
Before continuing, you should read this first to understand the behavior of NEXT FIELD NEXT/PREVIOUS:

https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/MultipleDialogs.html#NEXT_FIELD

Especially in a multiple dialog context:

1- When in INPUT, CONSTRUCT or DISPLAY ARRAY, NEXT FIELD PREVIOUS within first field of sub-dialog and NEXT FIELD NEXT within last field or a sub-dialog jump to another sub-dialog. This is not the case with INPUT ARRAY: We always stay in the current row...
=> What should NEXT FIELD FIRST/LAST do when in an INPUT ARRAY sub-dialog?
To be consistent with NEXT FIELD NEXT/PREVIOUS, it should stay in the current row and select first or last column respectively.
But I guess this is not what you expect.... right?

2- When doing a NEXT FIELD NEXT/PREVIOUS to an non-editable field like a NOENTRY or a LABEL, the focus jumps to the next editable field (goes always forward, does not matter if NEXT or PREVIOUS was used).
=> What should NEXT FIELD LAST do if the last field is not editable?
Should it jump to the first editable field and the top of the form or do you expect the down-most editable field to be selected?

I guess what you expect is that NEXT FIELD FIRST selects the first editable field, starting from the very first field used in the whole DIALOG, and NEXT FIELD LAST selects the down-most editable field used in the whole DIALOG.

Right?

[.]

Hi Sebastian,

Thanks for the reply. I'll answer from my own personal needs on this based upon what will work within our application. The requirement comes from wanting to standardise more code, as well as include segments of code using #include, which are often whole input statements, display/input array statements etc. This can lead to a section of code being unaware of what will be around it within a DIALOG and whilst we can cope with much of this within the individual statements the FIRST/LAST field of a DIALOG is more difficult than it could be, or requires us to use more non standard code when we might not need to.

To that end, here are my answers to your questions:

1) It should always go to the FIRST/LAST field in the DIALOG rather than the INPUT ARRAY.
2) I mostly agree with your definition, although the term 'editable' perhaps needs to be 'active'. If you can tab to the field it should be classed 'active', therefore a DISPLAY ARRAY at top or bottom would get control where appropriate, even though there would be no 'editable' fields. So you could define it as - FIRST would go to the top most field in a DIALOG that could be tabbed to before it wraps to the last tabbable field in the dialog, and LAST would do likewise at the bottom of the DIALOG, picking the bottom most field that can be tabbed to before it would wrap to the top of the DIALOG.

I hope that's clear (though fear it's not!)

Thanks

Jeff

Ok, I started to look if NEXT FIELD FIRST / LAST could be supported.

Basically it's not a big deal to extend the syntax and support FIRST/LAST keywords, but we must clearly specify what these do.
Actually FIRST/LAST would be part of the so called "abstract" field specifications for NEXT FIELD, like PREVIOUS, NEXT and CURRENT.
Before continuing, you should read this first to understand the behavior of NEXT FIELD NEXT/PREVIOUS:

https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/MultipleDialogs.html#NEXT_FIELD

Especially in a multiple dialog context:

1- When in INPUT, CONSTRUCT or DISPLAY ARRAY, NEXT FIELD PREVIOUS within first field of sub-dialog and NEXT FIELD NEXT within last field or a sub-dialog jump to another sub-dialog. This is not the case with INPUT ARRAY: We always stay in the current row...
=> What should NEXT FIELD FIRST/LAST do when in an INPUT ARRAY sub-dialog?
To be consistent with NEXT FIELD NEXT/PREVIOUS, it should stay in the current row and select first or last column respectively.
But I guess this is not what you expect.... right?

2- When doing a NEXT FIELD NEXT/PREVIOUS to an non-editable field like a NOENTRY or a LABEL, the focus jumps to the next editable field (goes always forward, does not matter if NEXT or PREVIOUS was used).
=> What should NEXT FIELD LAST do if the last field is not editable?
Should it jump to the first editable field and the top of the form or do you expect the down-most editable field to be selected?

I guess what you expect is that NEXT FIELD FIRST selects the first editable field, starting from the very first field used in the whole DIALOG, and NEXT FIELD LAST selects the down-most editable field used in the whole DIALOG.

Right?

[Sebastien F.]

Thank you Jeff this is perfectly clear to me, and is the need I expected.

We'll appreciate any other customer input, this is always valued information to design a new feature.

Another option could be to implement the behavior you expect with other keywords such as START/END:

NEXT FIELD START
NEXT FIELD END

We would keep the door open to FIRST/LAST for the other behavior (closer to NEXT/PREVIOUS).

Would that make sense for a native English speaker?

Seb

[Reuben B.]

I'll play devils advocate :-)

"If you can tab to the field it should be classed 'active'", what if a field has TABINDEX=0?  It can't be tabbed to but it could visually appear to be the first and/or last field.  Should a field with TABINDEX=0 be a candidate for first or last field.

You have 3 fields, field1 is initially disabled so when you first enter the dialog you are in field 2.  You then enable field1, should NEXT FIELD FIRST goto field1, or field2?

Using START to mean one thing and FIRST to mean another is problematic as you won't remember which is which.  You should use the same term but a prefix/suffix to extend its meaning e.g. NEXT FIELD VERY FIRST, the first field in the whole dialog, NEXT FIELD FIRST, the first field in the current dialog

Ideally the use of FIRST|PREVIOUS|NEXT|LAST should be analogous to the use of the same terms in  FETCH FIRST|PREVIOUS|NEXT|LAST

I'd be tempted to go with NEXT FIELD FIRST, NEXT FIELD LAST for the first/last fields of the DIALOG and NEXT FIELD dialog-name.FIRST, NEXT FIELD dialog-name.LAST for the first/last fields of a sub-dialog.

[.]

Well, ok then smartypants ;-)

Very good point, and I must admit I don't use TABINDEX=0 much so it's possibly less important to me than some others so other feedback would be good. For me though - if it's the first active field (to now include fields that can clicked with a mouse) then it would get focus from NEXT FIELD FIRST even if TABINDEX=0 (and vice versa for NEXT FIELD LAST).

If field1 has become active then it is the first field, if it's still disabled it's not, regardless of it's state when the DIALOG was first entered.

I also agree about START/FIRST could cause some confusion, although can't say I'm that bothered. Perhaps NEXT FIELD DIALOG FIRST (or actually, I think DIALOG START will read better) and NEXT FIELD FIRST (for the sub dialog) would work. Not keen on the NEXT FIELD dialog-name.FIRST as this adds extra complication for later maintenance.

This would thus read

ON ACTION myaction1
     NEXT FIELD DIALOG START -- (or NEXT FIELD DIALOG FIRST)

ON ACTION myaction2
     NEXT FIELD FIRST

Jeff

[Sebastien F.]

If the first item of the form has TABINDEX=0, when you start a dialog in FIELD ORDER FORM, this item will not be selected as the first item... To be consistent, I believe NEXT FIELD START/FIRST should NOT select items with TABINDEX=0.

Regarding the syntax, I would prefer to keep it simple with one additional keyword only.

NEXT FIELD START/END = what you request (new behavior, DIALOG wide).
NEXT FIELD FIRST/LAST = similar to PREVIOUS/NEXT behavior

That looks less confusing to me.

Seb