FWD » Core Development » Base Language

So, this works if we remove the assign:

define temp-table tt1 field f1 as integer extent 5.
form f1.

assign f1[1]:font  = 5.
f1[2]:font  = 5.

         0.setFont(new integer(5));
         frame0.widgetF1Array1().setFont(new integer(5));

I finally figured that this issue was fixed in the past, but only for <function name="search_widget"> (<!-- locate widget in the defined frames and return reference to frame -->). This condition is also needed in <function name="search_widget_in_outer_scopes"> (<!-- search widget in open scopes -->).

=== modified file 'rules/annotations/frame_scoping.rules'
--- old/rules/annotations/frame_scoping.rules    2025-03-25 11:48:45 +0000
+++ new/rules/annotations/frame_scoping.rules    2025-09-22 11:44:35 +0000
@@ -4591,6 +4591,12 @@
                                  txt1.equals(txt2)
                               <action>res = frame</action>
                            </rule>
+
+                           <!-- check item of EXTENT field -->
+                           <rule>node.getNumImmediateChildren() == 1 and
+                                 txt1.equals(txt2)
+                              <action>res = frame</action>
+                           </rule>
                         </rule>

                         <rule>is_w and nm.equals(ref.text.toLowerCase())

Andrei, can you test this patch for #10566-12 ?

Stefanel Pezamosca wrote:

I created task branch 10597a and committed the patch in revision 16177.
Please review!

The changes make sense. Please continue with testing.

There are other cases that need to be addressed. Andrei notified me that the conversion failed with the same output. So, I modified the testcase by adding with frame and the fix in 10597a does not work for this.

define temp-table tt1 field f1 as integer extent 5.

form 
    f1
with frame main01.

assign
    f1[1]:font = 5
    f1[2]:font = 5
    f1[3]:font = 5
    f1[4]:font = 5
    f1[5]:font = 5.

• array_expansion.rules: Mark created prog.num_literal nodes with is-literal annotation.

I also attached the full patch for 10597a.

I am OK with the latest changes from 10597a (I think there is is typo in note 12: 10579a).

Please merge 10597a to trunk now.

Branch 10597a was merged into trunk as rev. 16275 and archived.

I got notified that the change from this task caused another regression that can be reproduced by this testcase:

DEFINE TEMP-TABLE ttm
FIELD ext AS INTEGER EXTENT 4 format "->,>>>,>>9".

CREATE ttm.
ASSIGN
    ttm.ext[1] = 0
    ttm.ext[2] = 0
    ttm.ext[3] = 0
    ttm.ext[4] = 0.

form
  space(3) ttm.ext[1] label "ext1" format "9" 
  space(3) ttm.ext[2] label "ext2" format "9" 
  space(3) ttm.ext[3] label "ext3" format "9" 
  space(3) ttm.ext[4] label "ext4" format "9" 
  with frame frArc
  with centered side-label row 3.

ttm.ext[4] = 0.
display ttm.ext[4] with frame frarc.

repeat:
  update ttm.ext[4] with frame frarc.
  message "You entered: " ttm.ext[4].

  if input ttm.ext[4] > 3 then do:
      message "greater than 3".
      end.
  pause 1 no-message.
end.

I already understand that it is because of this rules because they are not checking for the extent index just the name:

+                     <!-- check item of EXTENT field -->
+                     <rule>node.getNumImmediateChildren() == 1 and
+                           txt1.equals(txt2)
+                        <action>res = ref</action>
+                     </rule>

I have a fix prepared in 10597b.patch and attached here. I will commit to a branch for review tomorrow after running some more tests from #10597.
Delia, please check it out also.

Previous patch had a NPE.
I created task branch 10597b from trunk revision 16350.

Committed the fix in revision 16351. Please review!

Review of 10597b / r16351.

I think the code is OK 👍.
My OCD: there is a misaligned variable definition at line 4271 😠.

Stefanel, there is a regression in trunk in rev 16275:

def var ch as char.
def var j as int.
def var i as int extent 5.
def temp-table tt1 field f1 as int extent 5.

find first tt1.
form tt1.f1 with frame f1.
form i with frame f2.

ch = input i[j].
ch = input tt1.f1[j].

if input tt1.f1[j] = j then message "good".
if input i[j] = j then message "good".

ch = input i[2].
ch = input tt1.f1[2].

if input tt1.f1[2] = j then message "good".
if input i[2] = j then message "good".

Instead of emitting getF1Array or getF1Array1 it emits getF1Array0; this for some reason happens only for temp-table extent fields which are part of a frame. The root cause is this rule added in search_widget_in_frame:

                     <!-- check item of EXTENT field -->
                     <rule>node.getNumImmediateChildren() == 1 and
                           txt1.equals(txt2)
                        <action>res = ref</action>
                     </rule>

For some reason this does not match on the LPARENS child, although this is done in a prior rule:

                     <rule>node.getChildAt(0) != null and 
                           ref.getChildAt(0) != null  and
                           txt1.equals(txt2)          and
                           node.getChildAt(0).compareWith(ref.getChildAt(0))
                        <action>res = ref</action>
                     </rule>

Constantin Asofiei wrote:

Stefanel, there is a regression in trunk in rev 16275:
[...]

Instead of emitting getF1Array or getF1Array1 it emits getF1Array0; this for some reason happens only for temp-table extent fields which are part of a frame. The root cause is this rule added in search_widget_in_frame:
[...]

For some reason this does not match on the LPARENS child, although this is done in a prior rule:
[...]

Did you checkout 10597b? It should fix the issue. It is not in trunk yet. A similar issue was already discussed and worked on, check the previous notes from #10597-25.

I fixed the issue. The problem was that when doing txt1.equals(txt2), in some cases txt1 was just i, while txt2 was i[1], i[2], etc.

Previously, there was a variable dyn used to avoid computing txt2 in search_widget when the first node had a dynamic index. I had removed it while making my changes, but I’ve now reintroduced it, which resolves the issue.

Committed the fix in 10597b revision 16352.

The changes look good.

Stefanel, please merge 10597b to trunk now.

Branch 10597b was merged into trunk as rev. 16368 and archived.