How to see dialogues/ sub dialogues and associated fields

[Stephen T.]

Is there a way to see an active dialogue?
I have a couple of dialogues made up of sub dialogues. In a sub dialogue I want to jump to field in another part of the overall dialogue (in another sub dialogue) depending upon certain conditions, but I'm getting a 'field name not in form' type error. So what I want is to be able to see which fields form part of the dialogue and which dialogue is active - I couldn't see that in the debug tree. Is that available anywhere?

[Sebastien F.]

Stephen,

I don't think you need to inspect the AUI tree to know what sub-dialog / fields are active...

In your code, according to the context, you should know what sub-dialog/fields are active or not (you decided to enable/disable fields)

Maybe your error is due to an invalid field name?

Here a link to the most recent V 3.00 BDL doc (part of the EAP program, please register to the EAP if not yet done!)

https://4js.com/techdocs/fjs-fgl-manual/#c_fgl_prog_dialogs_set_focus.html

https://4js.com/techdocs/fjs-fgl-manual/#c_fgl_dialog_NEXT_FIELD.html

Could you provide some code example?
Ideally a reduced sample that we can execute here.

Seb

[Stephen T.]

Seb,
The issue was caused by using an explicit field name in the NEXT FIELD clause. IE I used the below:

DIALOG sd_displayDetArray()
CONSTANT lc_tBType                             STRING = 'displayDetArray',
          lc_acceptType                         STRING = 'input',
          lc_cancelType                         STRING = 'input'

    DISPLAY ARRAY m_detArr1 TO detArr.*
        BEFORE DISPLAY
           -- Set the cancel and accept toolbar entries
            CALL ext_om_toolbar('Maint','accept',lc_acceptType)
            CALL ext_om_toolbar('Maint','cancel',lc_cancelType)
            CALL toolBarItems(lc_tBType,'0')

        BEFORE ROW
            LET m_detArrI                  = ARR_CURR()
            CALL det_toRec(m_detArr2[m_verArrI,m_detArrI].*)
                RETURNING m_det.*
            DISPLAY m_det.*             TO det.*

        ON ACTION add
            LET m_detArrI               = 0
            CALL default_detail(m_detArrI)
--RE--            NEXT FIELD det.filescontaining
            NEXT FIELD filescontaining

        ON ACTION delete
            LET m_detArr1[m_detArrI].deleted     = TRUE

    END DISPLAY

END DIALOG


...and from the form:
LABEL       laj:labelaj,TEXT=%'Files Containing',JUSTIFY=RIGHT,
                        STYLE='Label01';
EDIT        aj      =   det.filesContaining,SCROLL,
                        STYLE='Edit01';
.....
...which I thought was valid in DIALOG/SUB DIALOG - as soon as I commented out that line and replaced it with the unqualified name, the error stopped.

Irrespective though, it would have helped if the debug-tree had shown the active dialogue and fields then active acroos the sub dialogs.

[Sebastien F.]

Please try with the detArr. prefix as you use:

Code (genero) Select Expand

   DISPLAY ARRAY m_detArr1 TO [b]detArr[/b].* ...

Seb

[Stephen T.]

Seb,
But the filescontaining field that I want to move to is not in that sub dialog - the 'Add' option in this case jumps out of the array to a 'standard' record input. The filescontaining field I want to move to is the field shown in the form extract - that field is bound to detRec in the form, and is defined in the form as det.filescontaining.

So are you saying that if I want to explicitly point  to a field in the form I should initially use the SCREEN RECORD as the name qualifier - ie in this case NEXT FIELD detRec.filescontaining rather than using the [tablename|FORMONLY].fieldname actually used in the form field definition?

[Reuben B.]

Stephen,

To answer your original question, look at the active and tabIndexRt properties of the individual FormField nodes in the debug tree.  Note if the values are non-zero and/or if they have been changed by the runtime (displayed in bold).

Also I have said it a few times in the EAP, break the problem down to a small example.  So look at the attached and note what works and what does not work for doing a NEXT FIELD to a field in the INPUT part of a DIALOG statement.  (I'll also point out your example does not have an INPUT statement as part of the DIALOG, not sure if you omitted in copying code to the forum, but NEXT FIELD is for fields in the current dialog)

Reuben





 

[Stephen T.]

Stephen,

To answer your original question, look at the active and tabIndexRt properties of the individual FormField nodes in the debug tree.  Note if the values are non-zero and/or if they have been changed by the runtime (displayed in bold).

Also I have said it a few times in the EAP, break the problem down to a small example.  So look at the attached and note what works and what does not work for doing a NEXT FIELD to a field in the INPUT part of a DIALOG statement.  (I'll also point out your example does not have an INPUT statement as part of the DIALOG, not sure if you omitted in copying code to the forum, but NEXT FIELD is for fields in the current dialog)

Reuben

Thanks Reuben. I'm not sure going through the whole form via the debug tree is better than just going back to the form. I had thought that the DIALOG entry in the debug tree may have given me what I wanted, but if it doesn't, fine.

The problem was me misreading the manual on multiple dialogs - the 2.50 version reads:
'...Instead of the NEXT FIELD instruction, you can use the DIALOG.nextField("field-name") method
to register a field, for example when the name is not known at compile time. However, this method only
registers the field: It does not stop code execution, like the NEXT FIELD instruction does. You must
execute a CONTINUE DIALOG to get the same behavior as NEXT FIELD.
With the NEXT FIELD instruction, fields are identified by the form field name specification, not the program
variable name used by the dialog. Form fields are bound to program variables with the binding clause of
dialog instruction (INPUT variable-list FROM field-list, INPUT BY NAME variable-list,
CONSTRUCT BY NAME sql ON column-list,CONSTRUCT sql ON column-list FROM field-
list, INPUT ARRAY array-name FROM screen-array.*).
The field name specification can be any of the following:
•
•
•
•
field-name
table-name.field-name
screen-record-name.field-name
FORMONLY.field-name
Here are some examples:
•
•
•
•
•
"cust_name"
"customer.cust_name"
"cust_screen_record.cust_name"
"item_screen_array.item_label"
"formonly.total"
...'

I misread that as saying that any of the field naming formats are valid - but from Seb's reply, I now see that it is enforcing the binding rule - so whatever naming convention is used on the main INPUT/DISPLAY...etc statement is what I should have used in the code. IE in my case the INPUT statement (that I didn't post) binds the 4gl record m_det to a screen record named detRec. So I should have used either 'filescontaining' or the explicit 'detRec.filescontaining' NOT the actual field name from the form (det.filescontaining).

You're right, I didn't post all the code, just the sub dialog with the statement that was failing. Apologies. Also, your comment:
'...(I'll also point out your example does not have an INPUT statement as part of the DIALOG, not sure if you omitted in copying code to the forum, but NEXT FIELD is for fields in the current dialog)...'
..I take it there that where you say 'dialog' you mean the complete dialog, including sub-dialogs? You're not trying to say that NEXT FIELD is just for the 'immediate' dialog (ie only valid at base dialog level)?

[Reuben B.]

You're right, I didn't post all the code, just the sub dialog with the statement that was failing. Apologies. Also, your comment:
'...(I'll also point out your example does not have an INPUT statement as part of the DIALOG, not sure if you omitted in copying code to the forum, but NEXT FIELD is for fields in the current dialog)...'
..I take it there that where you say 'dialog' you mean the complete dialog, including sub-dialogs? You're not trying to say that NEXT FIELD is just for the 'immediate' dialog (ie only valid at base dialog level)?

Correct, complete dialog including sub-dialogs.  The runner knows about all the fields in the dialog.

[Stephen T.]

Ok - that's what I  thought anyway. I had assumed that you couldn't jump between dialogues (or else they would be sub dialogues anyway)