next »

[Andrew C.]

Given record array definition:

Code

p_rebatl dynamic array of record      # Record like the sre025a screen
    _seqno2 integer,
    id integer,
    parid integer,
    itm_no decimal(7,3),
    pay_ref like aurebatl.pay_ref,
    bnk_bsb like aurebatl.bnk_bsb,
    rcp_amt like aurebatl.rcp_amt,
    rcp_typ like aurebatl.rcp_typ,
    fmt_acc like aurebatl.fmt_acc,
    rcp_nm1 like aurebatl.rcp_nm1,
    rcp_val like aurebatl.rcp_val
end record,
 

Tree image (in part)

Code

tree s_dsre025a (idcolumn=id, parentidcolumn=parid, doubleclick=dclick)
 

field attribute definitions:

Code

PHANTOM formonly._seqno2 type integer;
PHANTOM formonly.id type integer;
PHANTOM formonly.parid type integer;
D0 = formonly.itm_no type decimal, format="&&&&.&&&", noentry;
D2 = aurebatl.pay_ref, width=17;
BUTTONEDIT D3 = aurebatl.bnk_bsb, picture="###-###", action=zoom, image="c_zoom_11";
D4 = aurebatl.rcp_amt, format="---------$&.&&", unhidable;
BUTTONEDIT D5 = aurebatl.rcp_typ, unhidable, action=zoom, image="c_zoom_11";
BUTTONEDIT D6 = aurebatl.fmt_acc, upshift, unhidable, action=zoom, image="c_zoom_11";
D7 = aurebatl.rcp_nm1, unhidable;
D8 = aurebatl.rcp_val, format="---------$&.&&", unhidable;
 

And screen array definition:

Code

screen record s_dsre025a[10] (formonly._seqno2, formonly.id, formonly.parid,
    formonly.itm_no, aurebatl.pay_ref, aurebatl.bnk_bsb, aurebatl.rcp_amt,
    aurebatl.rcp_typ, aurebatl.fmt_acc, aurebatl.rcp_nm1, aurebatl.rcp_val)
 

The following code:

Code

display "DRAWING ", m + n, " to ", n
display p_rebatl[m + n].* to s_dsre025a[n].*
 

is crashing with:

Code

DRAWING           1 to      1
Program stopped at 'detail.4gl', line number 1384.
FORMS statement error number -6327.
Internal error in the run time library file myWindow.c(1745):
mydom_getAttrNode(f, A_colName).
 

However when I replace the display code with:

Code

display "draw ", m + n, " to ", n
display p_rebatl[m + n]._seqno2 to s_dsre025a[n]._seqno2
display p_rebatl[m + n].id to s_dsre025a[n].id
display p_rebatl[m + n].parid to s_dsre025a[n].parid
display p_rebatl[m + n].itm_no to s_dsre025a[n].itm_no
display p_rebatl[m + n].pay_ref to s_dsre025a[n].pay_ref
display p_rebatl[m + n].bnk_bsb to s_dsre025a[n].bnk_bsb
display p_rebatl[m + n].rcp_amt to s_dsre025a[n].rcp_amt
display p_rebatl[m + n].rcp_typ to s_dsre025a[n].rcp_typ
display p_rebatl[m + n].fmt_acc to s_dsre025a[n].fmt_acc
display p_rebatl[m + n].rcp_nm1 to s_dsre025a[n].rcp_nm1
display p_rebatl[m + n].rcp_val to s_dsre025a[n].rcp_val
 

it works fine. I can't say it's the fault of the tree control or the phantom fields, but I've previously used phantom fields with a table so I'm guessing the problem is with the tree control.

Is this enough info for someone to understand, or do you need a trimmed-down sample program? I would expect any simple sample should manifest the problem, but let me know if you need me to trim my program down to the essential failure.

Version of BDL (32bit) is 2.20.09 on Linux, and GDC is 2.20.15-2168.12

[Reuben B.]

My first instinct was to say can we do tree widgets via a DISPLAY statement like this?  Reading through the docs I found ...

"The data used to display tree-view nodes must be provided in a program array and controlled by a DISPLAY ARRAY. It is possible to control a tree-view table with a singular DISPLAY ARRAY or with a DISPLAY ARRAY sub-dialog within a DIALOG instruction. "

... which would imply that you can't. 

If you are using a DISPLAY ARRAY and are using DISPLAY TO to change the values of an existing entry why not use UNBUFFERED? then you wouldn't need the DISPLAY TO in the first place

[Andrew C.]

Well, the stuff is read into the array and then shown to the user. The user isn't necessarily going to go into INPUT ARRAY or DISPLAY ARRAY immediately. attempting to use DISPLAY ARRAY or an unbuffered INPUT ARRAY would be a return to the bad old days:

Code

# any grammatical errors unintentional......
display array p_thingy.* to s_thingy.*
  on idle 1 exit display
end display
 

Further, the individually listed fields are entirely equivalent to the .* I've replaced. So if displaying the fields one at a time is legitimate, there must be a bug in the implementation of .* when it comes to TREE.

My guess is that, because the fields are hitting the array all at once, the code which is attempting to resolve the parent id links is hitting a problem - something in the algorithm can't cope with all the data landing at the same time.

I've adjusted the code generator to expand the field list for trees, so I can continue implementing them, but I'd prefer to get back to the simpler code. I expect the runtime codesters will be able to know where the fault lies fairly quickly (can't predict the cost of repair though ;-)

[Andrew C.]

ahhhhhhh nuts! I've just run the test program, and NOW it becomes clear to me that INPUT ARRAY is not supported - not mentioned in the 2.20 BDL manual. It does in fact work in a stuttering kind of way, but the focus is not always obvious, it seems to be very slow to move around, and there's no actual ability to edit the fields in the tree.

I can understand how INPUT ARRAY on a tree poses a challenge for the runtime; but is there intention to ever make it work properly?

[Rene S.]

Hello,
a DISPLAY TO statement can not be used when using a TREE. The tree requires additional rendering information.

Why fglrun throws the internal error? The DISPLAY .. TO screen_record.* statement expects any child of the screen-record being a form-field. This is not always true (and the code is not prepared for those exceptions).

These are the exceptions:
- when using multiple row selection: the runtime adds RowInfo nodes to the table
- when using a tree: the runtime adds TreeInfo nodes to the table.

In other words: fglrun will die with the same error if you use DISPLAY .. TO screen_record.* to any table once used with multiple row selection.

[Andrew C.]

Thanks for the reply, however I'm not sure I understand it. The case of DISPLAY individual fields is successful, so this doesn't make sense to me.

[Rene S.]

Sorry for confusing.

Name it a bug.
bug1: fglrun dies when using DISPLAY .. TO screen_record.* if the screen_record is a Tree.
bug2: fglrun dies when using DISPLAY .. TO screen_record.* if the Table has been used in multiple row selection mode.

Rene

[Christine R.]

Hello,

The 2 following problems have been registered in our database:
#17256 : fglrun dies when using DISPLAY .. TO screen_record.* if the screen_record is a Tree.
#17258 : fglrun dies when using DISPLAY .. TO screen_record.* if the Table has been used in multiple row selection mode

Best regards,

Christine HEIM-REBIERE
Four J's Support Team

[Andrew C.]

Thanks guys, now onto another big Tree control issue: Editing the data. I tried to use INPUT ARRAY and was disappointed to see it did not work. Should this be another call rather than extending this one?