Project

General

Profile

Bug #2099

"ASSIGN widget." statement does not convert properly in some cases

Added by Constantin Asofiei about 11 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Constantin Asofiei
Target version:
FWD - Conversion Support for Server Features
Start date:
03/19/2013
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:

ca_upd20130321a.zip (31.8 KB) Constantin Asofiei, 03/21/2013 08:58 AM

ca_upd20130321c.zip (31.8 KB) Constantin Asofiei, 03/21/2013 11:41 AM

History

#1 Updated by Constantin Asofiei about 11 years ago

This case was exposed by server folder compilation, in #2068 note 172:

def var i as int.
def var j as int.
form i j with frame f1.
do with frame f1:
   update i j.
end.
assign i j.

The conversion of the assign i j. statement does not link the i and j widgets with the f1 frame; instead, it puts them in the implicit frame. Interestingly, if the update statement in the do block is removed (or if is replaced with update i j with frame f1), the code converts OK. Note that the 4GL uses frame f1 for the assign i j., as the following test proves it:
def var i as int.
def var j as int.
form i j with frame f1.
do with frame f1:
   prompt-for i j.
end.
message i j. /* this shows the initial values before prompt-for */
assign i j.
message i j. /* this shows the entered values */

I'm putting here also an interesting 4GL behavior found by Ovidiu, during some view stream rpt tests. Although P2J converts it the same as 4GL does, the behavior is interesting in terms of frame scoping:

define variable c as char.
form c with frame f1 title "explicit".
form c.

c = "bar".
display c with frame f1.
hide c in frame f1.
view c in frame f1.

display c.
hide c. /* c in frame f1 is targeted, even no explicit frame is used */
pause.
view c. /* c in frame f1 is targeted, even no explicit frame is used */

#2 Updated by Constantin Asofiei about 11 years ago

This is a fix attempt for this issue. Looks like the solution was to explicitly set the frame name, in case the "frame referer" statement didn't explicitly refer a frame, but a frame name was resolved for it (due to a "strong reference" frame scope).

I'm putting this through conversion regression testing.

#3 Updated by Constantin Asofiei about 11 years ago

I'm still missing something, lots of invalid changes in MAJIC.

#4 Updated by Constantin Asofiei about 11 years ago

This update has passed conversion regression testing. There are some changes in MAJIC, but they do not affect runtime or logic (for some reason, a widget expression's index is changed for a frame, in the MemoProgramFList.java frame).

#5 Updated by Greg Shah about 11 years ago

This looks good. Check it in and distribute it.

#6 Updated by Constantin Asofiei about 11 years ago

  • Status changed from WIP to Review

Check it in and distribute it.

Committed to bzr revision 10308.

#7 Updated by Greg Shah about 11 years ago

  • Status changed from Review to Closed

#8 Updated by Greg Shah over 7 years ago

  • Target version changed from Milestone 4 to Conversion Support for Server Features

Also available in: Atom PDF