Bug #2714: demo/calc.p is broken - User Interface - Golden Code Redmine

Bug #2714

Bug #2677: fix drawing and functional differences between P2J GUI and 4GL GUI

demo/calc.p is broken

Added by Greg Shah over 8 years ago. Updated over 7 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Eugenie Lyzenko

Target version:

FWD - GUI Support for a Complex ADM2 App

Start date:

Due date:

% Done:

100%

billable:

vendor_id:

GCD

case_num:

calc.p_p2j_failure_20150914.png (5.36 KB) Greg Shah, 09/14/2015 05:26 PM

calc.p_in_4gl_20150914.png (4.78 KB) Greg Shah, 09/14/2015 05:26 PM

calc.p_p2j_web_failure_20150914.png (7.83 KB) Greg Shah, 09/15/2015 09:06 AM

calc_p2j_20151015.jpg - Calc P2J bugged 20151015 (30.4 KB) Eugenie Lyzenko, 10/15/2015 09:57 PM

calc_p2j_20151016.jpg - Calc P2J fix (41.9 KB) Eugenie Lyzenko, 10/16/2015 12:04 PM

calc_fix_to_commit_p2j_20151016.jpg - Calc is working (42.1 KB) Eugenie Lyzenko, 10/16/2015 12:52 PM

History

#1 Updated by Greg Shah over 8 years ago

Target version set to Milestone 12
File calc.p_p2j_failure_20150914.png added
File calc.p_in_4gl_20150914.png added

In the trunk revision 10935, running demo/calc.p results in this screen:

There is a flash of a frame that looks pretty close to what should appear and then it is cleared and the result in the image is shown.

Here is what it is supposed to look like:

The client log only has this:

DRAW: Ignoring event com.goldencode.p2j.ui.client.event.PaintEvent 9 raised while drawing widget com.goldencode.p2j.ui.client.gui.ScrollBarGuiImpl with id [-3].
DRAW: Ignoring event com.goldencode.p2j.ui.client.event.PaintEvent 9 raised while drawing widget com.goldencode.p2j.ui.client.gui.ScrollBarGuiButton with id [-4].
DRAW: Ignoring event com.goldencode.p2j.ui.client.event.PaintEvent 9 raised while drawing widget com.goldencode.p2j.ui.client.gui.ScrollBarGuiButton with id [-5].
DRAW: Ignoring event com.goldencode.p2j.ui.client.event.PaintEvent 9 raised while drawing widget com.goldencode.p2j.ui.client.gui.ScrollBarGuiImpl with id [-3].
DRAW: Ignoring event com.goldencode.p2j.ui.client.event.PaintEvent 9 raised while drawing widget com.goldencode.p2j.ui.client.gui.ScrollBarGuiButton with id [-4].
DRAW: Ignoring event com.goldencode.p2j.ui.client.event.PaintEvent 9 raised while drawing widget com.goldencode.p2j.ui.client.gui.ScrollBarGuiButton with id [-5].

There is nothing in the server.log that relates to the failure.

#2 Updated by Greg Shah over 8 years ago

File calc.p_p2j_web_failure_20150914.png added

Interestingly, in the web client (task branch 1181q revision 11008), what is described above as "flashing" of the buttons leaves behind this:

Those "ghost" buttons are not interactive in any way. Somehow the web client doesn't clear or overdraw that area while the swing client does. The Swing client in 1811q revision 11008 acts the same way as the trunk revision 10935.

#3 Updated by Greg Shah over 8 years ago

Assignee set to Eugenie Lyzenko

#4 Updated by Eugenie Lyzenko over 8 years ago

File calc_p2j_20151015.jpg added

Debugging the issue. The situation become event more strange, the screen is attached.

The findings. At least one buggy point I have found. The call to set up calculator frame height/width fails with no respective change in FrameConfig. The 4GL code:

frame fcalc:height-pixels = btn0:y + btn0:height-pixels - tfRes:y + 30.
frame fcalc:width-pixels = btnEq:x + btnEq:width-pixels - btn0:x + 6.

converted to P2J:

fcalcFrame.setHeightPixels(plus(minus(plus(fcalcFrame.widgetBtn0().getY(), fcalcFrame.widgetBtn0().getHeightPixels()), fcalcFrame.widgetTfRes().getY()), 30));
fcalcFrame.setWidthPixels(plus(minus(plus(fcalcFrame.widgetBtnEq().getX(), fcalcFrame.widgetBtnEq().getWidthPixels()), fcalcFrame.widgetBtn0().getX()), 6));

It is happening when server pushes the updated screen definition.
LogicalTerminal, line 11717:

...
      WidgetConfig[] wcfgs = locate().client.pushScreenDefinition(screenDef);
...

Before this call the screen definition has new correct heightPixels/widthPixels values. But after call the values are undoing to the old ones from client side.

As a result calculator can not place the buttons inside the frame because there is no room space. Continue debugging.

#5 Updated by Greg Shah over 8 years ago

I've added Hynek and Constantin as watchers. They may have some ideas.

#6 Updated by Constantin Asofiei over 8 years ago

Eugenie, I think the problem is in Frame.postprocess:3145:

         else
         {
            adjustDown();
         }

The adjustDown() call alters the frame's size.

This is mostly caused by the fact that when setting the frame's width/height via attributes, the BaseConfig.fixedHeight and fixedWidth flags are not set... I don't know why we are not just calling FrameWidget.set[Height/Width][Pixels/Chars] APIs, and use a completely different logic in GenericFrame.set[Height/Width][Pixels/Chars] than in FrameWidget. The FrameWidget APIs are expected to be called when the frame is accessed via a handle, and the FRAME fname:attribute construct calls the GenericFrame versions, but in the end both should do the same thing.

Only exception is that the GenericFrame versions might have logic related to setting up the frame (i.e. in the frame's setup() method in its definition class, from any SIZE options set at the frame in 4GL).

#7 Updated by Eugenie Lyzenko over 8 years ago

File calc_p2j_20151016.jpg added

The main issue is in GenericFrame.set(Width|Height)(Chars|Pixels) methods. If we set the width or height by changing the frame attribute - we have to set the fixed(Width|Height) flag in frame config to true. And this logic was completely missed.

But this is not enough to fix calc.p. Another point is on client side the frameScroll class member. After config update the size of this real container become out of sync. So we have to sync it too by size changing. I'm preparing the update right now to have working calc.p demo.