Subscribe for automatic updates: RSS icon RSS

Login icon Sign in for full access | Help icon Help
Advanced search

Pages: [1]
  Reply  |  Print  
Author Topic: Tree control crashing on display p.* to s.*  (Read 14418 times)
Andrew C.
Posts: 48

« on: June 15, 2010, 05:46:54 am »

Given record array definition:
  1. p_rebatl dynamic array of record      # Record like the sre025a screen
  2.    _seqno2 integer,
  3.    id integer,
  4.    parid integer,
  5.    itm_no decimal(7,3),
  6.    pay_ref like aurebatl.pay_ref,
  7.    bnk_bsb like aurebatl.bnk_bsb,
  8.    rcp_amt like aurebatl.rcp_amt,
  9.    rcp_typ like aurebatl.rcp_typ,
  10.    fmt_acc like aurebatl.fmt_acc,
  11.    rcp_nm1 like aurebatl.rcp_nm1,
  12.    rcp_val like aurebatl.rcp_val
  13. end record,

Tree image (in part)
  1. tree s_dsre025a (idcolumn=id, parentidcolumn=parid, doubleclick=dclick)

field attribute definitions:
  1. PHANTOM formonly._seqno2 type integer;
  2. PHANTOM type integer;
  3. PHANTOM formonly.parid type integer;
  4. D0 = formonly.itm_no type decimal, format="&&&&.&&&", noentry;
  5. D2 = aurebatl.pay_ref, width=17;
  6. BUTTONEDIT D3 = aurebatl.bnk_bsb, picture="###-###", action=zoom, image="c_zoom_11";
  7. D4 = aurebatl.rcp_amt, format="---------$&.&&", unhidable;
  8. BUTTONEDIT D5 = aurebatl.rcp_typ, unhidable, action=zoom, image="c_zoom_11";
  9. BUTTONEDIT D6 = aurebatl.fmt_acc, upshift, unhidable, action=zoom, image="c_zoom_11";
  10. D7 = aurebatl.rcp_nm1, unhidable;
  11. D8 = aurebatl.rcp_val, format="---------$&.&&", unhidable;

And screen array definition:
  1. screen record s_dsre025a[10] (formonly._seqno2,, formonly.parid,
  2.    formonly.itm_no, aurebatl.pay_ref, aurebatl.bnk_bsb, aurebatl.rcp_amt,
  3.    aurebatl.rcp_typ, aurebatl.fmt_acc, aurebatl.rcp_nm1, aurebatl.rcp_val)

The following code:
  1. display "DRAWING ", m + n, " to ", n
  2. display p_rebatl[m + n].* to s_dsre025a[n].*

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

However when I replace the display code with:
  1. display "draw ", m + n, " to ", n
  2. display p_rebatl[m + n]._seqno2 to s_dsre025a[n]._seqno2
  3. display p_rebatl[m + n].id to s_dsre025a[n].id
  4. display p_rebatl[m + n].parid to s_dsre025a[n].parid
  5. display p_rebatl[m + n].itm_no to s_dsre025a[n].itm_no
  6. display p_rebatl[m + n].pay_ref to s_dsre025a[n].pay_ref
  7. display p_rebatl[m + n].bnk_bsb to s_dsre025a[n].bnk_bsb
  8. display p_rebatl[m + n].rcp_amt to s_dsre025a[n].rcp_amt
  9. display p_rebatl[m + n].rcp_typ to s_dsre025a[n].rcp_typ
  10. display p_rebatl[m + n].fmt_acc to s_dsre025a[n].fmt_acc
  11. display p_rebatl[m + n].rcp_nm1 to s_dsre025a[n].rcp_nm1
  12. 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.
Four Js
Posts: 1080

« Reply #1 on: June 15, 2010, 06:22:15 am »

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

Product Consultant (Asia Pacific)
Developer Relations Manager (Worldwide)
Author of
Contributor to
Andrew C.
Posts: 48

« Reply #2 on: June 15, 2010, 06:53:09 am »

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:

  1. # any grammatical errors unintentional......
  2. display array p_thingy.* to s_thingy.*
  3.  on idle 1 exit display
  4. 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.
Posts: 48

« Reply #3 on: June 15, 2010, 07:17:33 am »

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.
Four Js
Posts: 111

« Reply #4 on: June 15, 2010, 08:22:46 am »

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.
Posts: 48

« Reply #5 on: June 15, 2010, 08:32:01 am »

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.
Four Js
Posts: 111

« Reply #6 on: June 15, 2010, 09:18:47 am »

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.

Four Js
Posts: 424

« Reply #7 on: June 15, 2010, 01:11:06 pm »


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,

Four J's Support Team
Andrew C.
Posts: 48

« Reply #8 on: June 16, 2010, 01:44:00 am »

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?
Pages: [1]
  Reply  |  Print  
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines