FWD » Core Development » User Interface

The current P2J code converts

...
UNDERLINE WITH FRAME my-frame 5 DOWN.
...

...
            myFrameFrame.openScope();
            frame0.openScope();

            ;
...

...
   public static class UnderlineTest0MyFrameDef
   extends WidgetList
   {
      FillInWidget myVar1 = new FillInWidget();

      FillInWidget myVar2 = new FillInWidget();

      public void setup(CommonFrame frame)
      {
         frame.setDown(5);
         myVar1.setDataType("character");
         myVar2.setDataType("integer");
         myVar1.setLabel("my-var1");
         myVar1.setFormat("x(8)");
         myVar2.setLabel("my-var2");
      }

      {
         addWidget("myVar1", "my-var1", myVar1);
         addWidget("myVar2", "my-var2", myVar2);
      }
   }
...

The second question is for

UNDERLINE my-var2 WITH FRAME my-frame.

...
+-------------------+
|my-var1     my-var2|
|-------- ----------|
|         ----------|
|                   |
|                   |
|                   |
|                   |
+-------------------+
...

This is correct or not?

It is not 100% correct.

The converted code should not contain NOP?

Right. It should not contain that.

Make sure that this testcase works the same way as in the 4GL:

def var txt as char init "something".
define frame f0 txt.
underline with frame f0 5 down.
pause.
display txt with frame f0.

Do we need to debug it to verify the same behavior as in 4GL? The 4GL shows the frame with underlined entry:

It should already be working, but please do check it. If there are problems, document them here and fix them.

...
underline with frame f0 5 down.
...

...
;
...

However the behavior is the same(NOP just do nothing).

Is the behavior (especially AFTER the pause) the same as the 4GL?

Is the behavior (especially AFTER the pause) the same as the 4GL?

Yes, P2J does exactly the same as 4GL.

Good. Then the important thing to do is to eliminate the output of that ;. Take a close look at the AST and JAST files for this case. Identify the node that is being generated in the JAST that causes the ;. Track that back to it's "peer" in the AST. Then put the necessary protection rules in the TRPL ruleset(s) to detect this "empty" case and avoid emiting that JAST node.

Your solution is not correct. The 2nd parameter to descendant() is the number of levels of children (1 for the immediate children, 2 to include grandchildren...) to search. With your approach, all UNDERLINE statements that have a frame phrase will never emit.

It is also possible to have no children at all (this is also a NOP), as in:

UNDERLINE.

Try this:

<!-- avoid emitting code for empty underline statements (those with no widgets listed) -->
<rule>type == prog.kw_underlin and copy.numImmediateChildren &gt; 0 and copy.getChildAt(0).type != prog.frame_phrase
...

Code Review 0508a

I am fine with the change.

Are all the testcases working the same way in the 4GL and P2J? If so, then go ahead and run conversion regression testing. There is no need for runtime regression testing.

Yes, fix this.

I suspect this has something to do with the DOWN processing and the afterDown variable used in GenericFrame.underline(). The UNDERLINE is like an implicit DOWN, so it should cause some special behavior (like making the DISPLAY appear in the next iteration of the down frame). DOWN processing also causes pending output to be flushed. But normally on an interactive terminal (not redirected), flushing is not an issue.

I think you must carefully debug into the first DISPLAY statement (the missing one) to see where it "goes wrong".

The intermediate debugging results. The main issue is happening on the first UNDERLINE statement when there is nothing yet on the screen.

The control flow for not first underline and display is:
When underline processed it turn on frame repainting. The FrameImpl code looks for the underlined row and draws the horizontal line. Then when handling display statement FrameImpl code look for the down body and displays the widget content. So we have two separate drawing code and display command draw only widget values.

But on the first time when there is nothing yet on the screen the underline command does not make any output on the screen because there is no bitmap to render to. Then when handling display command FrameImpl code looks for the first objects to draw and these objects are the underlining, not the widget values. So in this case display command behaves as usual underline command and we need second painting to display the widget values after underlining.

Continue debugging.

Do you have an update on this? It seems like you should be pretty close to a solution, based on your findings.

Do you have an update on this? It seems like you should be pretty close to a solution, based on your findings.

Yes, I.m pretty close but still not have code that works. Looks like we need very special one time fix for cases when underline is called when frame is not on the screen. Unfortunately at this time the body of the down frame has no correct widget values, so adjustDownFrame() with underline does not work. I'm looking for solution to handle this situation on the first display call after this special underline. Hope to find solution later today(the code for frame repainting has a lot of very special processing I need to take into account to avoid regressions).

Finally I have the fix. The client side modification is not enough. We need to perform implicit down processing on the server side even if there is no frame on the screen during update command. Otherwise the data sent to client are not sufficient. And the client side needs to consider this special case additionally. I'll prepare and upload the update in a hour.

Code Review 0514a

The changes look good. I do wonder what happens if the Point.y value of the widget becomes negative during relocateComponent(). Are there any bad results that could happen?

I do wonder what happens if the Point.y value of the widget becomes negative during relocateComponent(). Are there any bad results that could happen?

I'm expecting the changes I made will work only for down frames that will have underlined widgets when the frame is not on the screen. I guess in usual case(when the frame is already visible) this special processing should be bypassed. But I agree, the negative y coords can produce screen mess or the widget will not be seen because location is out of the viewport rectangles. May be the changes need to be tested additionally.

can produce screen mess

If our clipping implementation is working properly, then a negative y value should not be a problem. However, there may be a flaw in our logic somewhere.

or the widget will not be seen because location is out of the viewport rectangles

Yes, perhaps this is an issue if the "current" row is ever able to be moved to a location that is invalid.

My primary concerns:

1. Can an unexpected y value (especially a negative one) cause problems in our code?
2. Can the general approach lead to unexpected state that breaks code currently working? In particular, can the "current" row (which is the row that can be edited and which should always be visible) ever be in a condition (moved to a location) which is not displayable in the down frame?

I think the best way to check this is to try to create testcases:

• that have the first row moved to an invalid y value
• that have the current row moved to an invalid y value

In other words: try to break this implementation. Report your results here. If you cannot break it, then go ahead into both conversion and runtime testing.

In other words: try to break this implementation. Report your results here. If you cannot break it, then go ahead into both conversion and runtime testing.

OK.

I have tested two possibilities:
- perform UP command for the first row in down frame several times.
- manual setting widget row attribute to negative value.

The result is:
- it is not possible to set row to negative by the UP command - 4GL moves the widget to the bottom of the frame when 1 coord is requested.
it is not possible to manually move the widget to negative position by changing the widget's ROW attribute - the 4GL displays the message and coord is not changing.

The P2J works almost the same with this testing. UP command moves the first row to the bottom of the frame and manual setting row to negative does not change anything. The only exception is P2J does not display the warning message that the Y coord can not be negative while 4GL displays the message. But I think this in not related to the current update changes. Or this is something we need to fix with this task too?

So I'm going to perform one more test involving the code that underlines the hidden widgets. This way we can be sure the modified code will be included into the process.

Well, the testcase to partially break implementation:

...
def var my-var1 as character initial "Hello".
def var my-var2 as integer initial 314.

DEFINE FRAME my-frame my-var1 my-var2.
UNDERLINE WITH FRAME my-frame 3 DOWN.

UNDERLINE my-var1 WITH FRAME my-frame.
DISPLAY my-var1 my-var2 WITH FRAME my-frame.
message "press any key to one line up.".
pause.

UP 1 WITH FRAME my-frame.
DISPLAY my-var1 my-var2 WITH FRAME my-frame.

message "press any key to two lines up.".
pause.

UP 2 WITH FRAME my-frame.
DISPLAY my-var1 my-var2 WITH FRAME my-frame.

message "press any key to one line up.".
pause.

UP 1 WITH FRAME my-frame.
DISPLAY my-var1 my-var2 WITH FRAME my-frame.

message "press any key to set row to -7 and -5.".
pause.

my-var1:row = -7.
my-var2:row = -5.
DISPLAY my-var1 my-var2 WITH FRAME my-frame.
...

The main issue I think is the P2J represents underline character as one of the element in down body(along with the widget itself). So when we have first line as underlined - we really have down body with two elements, the first is the underline and the second is the widget line. And if we moving them up - everything is moving I think. One I can tell is the negative coord is not set.

What do you think? Do we need to find and fix all underline deviations in this task? May be there is some subset of cases we need to provide the compatibility? I'm asking to just not to fix anything we will never encounter. What is our policy here?

The only exception is P2J does not display the warning message that the Y coord can not be negative while 4GL displays the message.

Please create a small testcase that shows this problem and open a new redmine task. Make sure to properly describe the problem and attach the testcase.

Moving UP the first row in 4GL does not change anything while in P2J it clears underlining and shifts underlined row one line UP.

Create a new redmine task for this problem, you can attach the testcase from note 25 as the recreate.

Do we need to find and fix all underline deviations in this task?

We will try to fix the problems with UNDERLINE. But the two problems above are more about UP than UNDERLINE, so we will defer those.

May be there is some subset of cases we need to provide the compatibility? I'm asking to just not to fix anything we will never encounter. What is our policy here?

As a general policy, we don't put limits on our compatibility. However, during the work on any given task we may choose to defer some work/bugs that are not immediately critical.

The primary issue here is that you are not really exercising the new code very much. Try something like this:

def var my-var1 as character initial "Hello".
def var my-var2 as integer initial 314.

DEFINE FRAME my-frame my-var1 my-var2.
UNDERLINE my-var1 WITH FRAME my-frame.
UNDERLINE my-var1 WITH FRAME my-frame.
UNDERLINE my-var1 WITH FRAME my-frame.
UNDERLINE my-var1 WITH FRAME my-frame.
UNDERLINE my-var1 WITH FRAME my-frame.
DISPLAY my-var1 my-var2 WITH FRAME my-frame.

Or this:

def var my-var1 as character initial "Hello".
def var my-var2 as integer initial 314.

DEFINE FRAME my-frame my-var1 my-var2.
UNDERLINE my-var1 WITH FRAME my-frame.
VIEW FRAME my-frame.
HIDE FRAME my-frame.
UNDERLINE my-var1 WITH FRAME my-frame.
VIEW FRAME my-frame.
HIDE FRAME my-frame.
UNDERLINE my-var1 WITH FRAME my-frame.
VIEW FRAME my-frame.
HIDE FRAME my-frame.
UNDERLINE my-var1 WITH FRAME my-frame.
VIEW FRAME my-frame.
HIDE FRAME my-frame.
UNDERLINE my-var1 WITH FRAME my-frame.
DISPLAY my-var1 my-var2 WITH FRAME my-frame.

Both of these are designed to trigger your code more than once, in an attempt to break it.

Greg Shah wrote:
...

The primary issue here is that you are not really exercising the new code very much. Try something like this:

[...]

Or this:

[...]

Both of these are designed to trigger your code more than once, in an attempt to break it.

I have tested these cases with the my changes for this task. The screen looks are absolutely the same for 4GL and P2J. So we can start the regression testing and fix the problems with UP(discovered in note 25) as another task. What do you think?

So we can start the regression testing and fix the problems with UP as another task. What do you think?

Yes.

The conversion test completed. The converted sources are binary equal. Continue with runtime regression testing.

The main part completed without regressions in a single run. Continue testing with CTRL-C part.

Code Review 0516a

I am fine with the changes. When CTRL-C processing passes, please check it in and distribute it.

Finally I have finished CTRL-C testing with all passed results. Not in single run.due to multiple false negative results. The problem is well known issue with:

...
|        ATT+---------------------- Message -----------------------+061A        
|        P.O| An error has occurred attempting to connect to the   |            
|        Wil│              selected database system.               |            
|           | ---------------------------------------------------- |            
...

So shortly the update will be committed and distributed.

The update 0516a has been committed to bzr as 10536.