FWD » Core Development » User Interface

This widget is supported for ChUI runtime usage today. It's conversion should be pretty complete, but I haven't checked what might be missing.

Please review the state of the current support. Document any missing conversion support here. Also document your plan for implementing the GUI widget.

Make sure to get this running for dynamic usage too.

You will have to test usage variants on windev01 to make sure that you are implementing the visual rendering exactly like the 4GL. The GUI event processing will also have to match perfectly.

About my implementation plan. I just think that I'll firstly implement drawing and after that I'll be implementing event processing. That's all my plan ). Is that what you meant?

Not exactly. What I meant is that I would like to see some specific findings about the drawing and event processing to explain the functionality that you have to implement. In other words, once you have testcases written to show the behavior which has to be implemented, describe that behavior here.

I didn't find any peculiarities. Here is the test:

def var h1 as handle. 
create window h1 assign title = "window".
current-window = h1.

def var logic as logical.
def var varother as logical.

logic = true.

def button exit_btn label "exit".
def frame f skip exit_btn.

view h1.

varother = ?.
display logic view-as toggle-box with frame f.
display varother view-as toggle-box with frame f.

enable all with frame f.
wait-for choose of exit_btn.

When we're trying to set the UNKNOWN value to to TOGGLE-BOX we are getting the error: Attribute SCREEN-VALUE for the TOGGLE-BOX ...has an invalid value UNKNOWN. (4056)

When we're trying to visualize the values of types other than logical using TOGGLE-BOX we're getting another error:
Data type for Toggle-box must be logical. (3376)

I faced with the following difficulty: running application window (GUI) has the size 1x1 and position in the first pixel (left top corner of the screen).

Here is the client log:

..
фев 12, 2015 5:52:40 PM com.goldencode.p2j.ui.client.FontManager getFontKey
SEVERE: Undefined font is not allowed - the caller needs to specify a resolved font.
фев 12, 2015 5:52:40 PM com.goldencode.p2j.ui.client.FontManager getFontKey
SEVERE: Undefined font is not allowed - the caller needs to specify a resolved font.
фев 12, 2015 5:52:42 PM com.goldencode.p2j.ui.client.FontManager getFontKey
..

And the server log:

[02/12/2015 17:55:46 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Could not load the legacy font metrics from file font-metrics.xml
[02/12/2015 17:55:46 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Could not load the legacy font metrics from file font-metrics-ext.xml
[02/12/2015 17:55:46 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Could not load the legacy text metrics from file text-metrics.xml
[02/12/2015 17:55:46 YEKT] (com.goldencode.p2j.ui.FontTable:WARNING) No custom fonts are defined in the directory.
[02/12/2015 17:55:46 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Font [system,10,false,false,false] has no legacy metrics.
[02/12/2015 17:55:47 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Text [Restore] has no legacy metrics with font [system,10,false,false,false].
[02/12/2015 17:55:47 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Text [Restore] has no legacy metrics with font [system,10,false,false,false].
[02/12/2015 17:55:47 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Text [Move] has no legacy metrics with font [system,10,false,false,false].
[02/12/2015 17:55:47 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Text [Move] has no legacy metrics with font [system,10,false,false,false].
[02/12/2015 17:55:47 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Text [Size] has no legacy metrics with font [system,10,false,false,false].
[02/12/2015 17:55:47 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Text [Size] has no legacy metrics with font [system,10,false,false,false].
[02/12/2015 17:55:47 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Text [Minimize] has no legacy metrics with font [system,10,false,false,false].
[02/12/2015 17:55:47 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Text [Minimize] has no legacy metrics with font [system,10,false,false,false].
[02/12/2015 17:55:47 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Text [Maximize] has no legacy metrics with font [system,10,false,false,false].
[02/12/2015 17:55:47 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Text [Maximize] has no legacy metrics with font [system,10,false,false,false].
[02/12/2015 17:55:47 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Text [Close] has no legacy metrics with font [system,10,false,false,false].
[02/12/2015 17:55:47 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Text [Close] has no legacy metrics with font [system,10,false,false,false].

It looks like misconfiguration. Where this GUI options has to be specified? Could you send me some example like client.xml or other needed?

Vadim Gindin wrote:

I didn't find any peculiarities. Here is the test:

[...]

Have you added basic runtime support for the TOGGLE-BOX widget? If not, then the client will not be able to create/initialize the GUI TOGGLE-BOX, and the behaviour will not be stable.

Please try a basic test with only this code:

message "this is a GUI client"!.

Thanks. I tried it and got the error:

..
[02/13/2015 00:32:08 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Text [Maximize] has no legacy metrics with font [system,10,false,false,false].
[02/13/2015 00:32:08 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Text [Maximize] has no legacy metrics with font [system,10,false,false,false].
[02/13/2015 00:32:08 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Text [Close] has no legacy metrics with font [system,10,false,false,false].
[02/13/2015 00:32:08 YEKT] (com.goldencode.p2j.ui.FontTable:SEVERE) Text [Close] has no legacy metrics with font [system,10,false,false,false].
[02/13/2015 00:33:38 YEKT] (StandardServer.invoke:SEVERE) {00000001:00000007:bogus} Abnormal end!
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at com.goldencode.p2j.util.Utils.invoke(Utils.java:1244)
        at com.goldencode.p2j.main.StandardServer$MainInvoker.execute(StandardServer.java:1772)
        at com.goldencode.p2j.main.StandardServer.invoke(StandardServer.java:1272)
        at com.goldencode.p2j.main.StandardServer.standardEntry(StandardServer.java:435)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at com.goldencode.p2j.util.MethodInvoker.invoke(MethodInvoker.java:76)
        at com.goldencode.p2j.net.Dispatcher.processInbound(Dispatcher.java:694)
        at com.goldencode.p2j.net.Conversation.block(Conversation.java:319)
        at com.goldencode.p2j.net.Conversation.run(Conversation.java:163)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
        at java.lang.String.substring(String.java:1911)
        at com.goldencode.p2j.ui.client.gui.MessageAreaGuiImpl.split(MessageAreaGuiImpl.java:399)
        at com.goldencode.p2j.ui.client.gui.MessageAreaGuiImpl.addMessage(MessageAreaGuiImpl.java:160)
        at com.goldencode.p2j.ui.client.gui.MessageAreaGuiImpl$1.run(MessageAreaGuiImpl.java:301)
        at com.goldencode.p2j.ui.chui.ThinClient.eventBracket(ThinClient.java:12374)
        at com.goldencode.p2j.ui.chui.ThinClient.eventDrawingBracket(ThinClient.java:12323)
        at com.goldencode.p2j.ui.client.gui.MessageAreaGuiImpl.setMessageText(MessageAreaGuiImpl.java:286)
        at com.goldencode.p2j.ui.client.gui.WindowGuiImpl.setMessageText(WindowGuiImpl.java:750)
        at com.goldencode.p2j.ui.client.gui.WindowGuiImpl.setMessageText(WindowGuiImpl.java:731)
        at com.goldencode.p2j.ui.client.Window.displayMessage(Window.java:2330)
        at com.goldencode.p2j.ui.client.Window.message(Window.java:1868)
        at com.goldencode.p2j.ui.client.Window.message(Window.java:2021)
        at com.goldencode.p2j.ui.chui.ThinClient.message(ThinClient.java:6200)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at com.goldencode.p2j.util.MethodInvoker.invoke(MethodInvoker.java:76)
        at com.goldencode.p2j.net.Dispatcher.processInbound(Dispatcher.java:694)
        at com.goldencode.p2j.net.Conversation.block(Conversation.java:319)
        at com.goldencode.p2j.net.Conversation.waitMessage(Conversation.java:257)
        at com.goldencode.p2j.net.Queue.transactImpl(Queue.java:1128)
        at com.goldencode.p2j.net.Queue.transact(Queue.java:585)
        at com.goldencode.p2j.net.BaseSession.transact(BaseSession.java:223)
        at com.goldencode.p2j.net.HighLevelObject.transact(HighLevelObject.java:163)
        at com.goldencode.p2j.net.RemoteObject$RemoteAccess.invokeCore(RemoteObject.java:1424)
        at com.goldencode.p2j.net.InvocationStub.invoke(InvocationStub.java:97)
        at com.sun.proxy.$Proxy4.standardEntry(Unknown Source)
        at com.goldencode.p2j.main.ClientCore.start(ClientCore.java:277)
        at com.goldencode.p2j.main.ClientCore.start(ClientCore.java:100)
        at com.goldencode.p2j.main.ClientDriver.start(ClientDriver.java:201)
        at com.goldencode.p2j.main.CommonDriver.process(CommonDriver.java:398)
        at com.goldencode.p2j.main.ClientDriver.process(ClientDriver.java:1)
        at com.goldencode.p2j.main.ClientDriver.main(ClientDriver.java:267)
..

I was trying to debug and found that MessageAreaGuiImpl.maxTextWidth got the value -8. I suppose it's incorrect. But if it is correct what a negative value mean?

I made the message text even shorter: just "Th". In spite of that MessageAreaGuiImpl all one to tried to split it and raise an error.

Vadim Gindin wrote:

Thanks. I tried it and got the error:
[...]

Are you using the latest P2J rev? Note that there is a typo in the test at note 6 (! is outside of the quotes), but this doesn't affect the test in P2J... it works OK with my setup.

display "This" behaves as the first test: window 1x1 in the left top corner.

Constantin Asofiei wrote:

Vadim Gindin wrote:

Thanks. I tried it and got the error:
[...]

Are you using the latest P2J rev? Note that there is a typo in the test at note 6 (! is outside of the quotes), but this doesn't affect the test in P2J... it works OK with my setup.

Yes, I'm using the latest P2J rev. I understand that it works for you. I thought that it because of wrong configuration...

Please archive your testcases/simple/server, testcases/simple/client folders and upload them to devsrv01.

How do you start the client? From your IDE (i.e. Eclipse) or using client.sh?

Done. I've uploaded vig_server_client.zip to /home/vig

I use Java configuration in Eclipse.

That is probably the issue. Try it from the command line.

Please merge this code with the latest version in bzr. Otherwise the code review is too difficult.

1. When I'm going between checkboxes I've faced with view affect (see attached image). Why it can happen?

Please check if this is still an issue. We have seen similar "ghosting" which was caused by a repaint() where the coordinates were not made relative to the parent container.

2. How to calculate real colors for checkbox lines? I just try them intuitively.

This should be defined by one of the Windows system colors. The important thing is to determine which one is used in Windows 4GL by changing the system color definitions one at a time and testing to see which one causes the lines to change. The 4GL is using the WIN32 API CreateWindowEx using a BUTTON type and a BS_CHECKBOX "style". The underlying WIN32 control will use one of the system colors for the lines.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms632680%28v=vs.85%29.aspx

3. I tried to draw objects with sizes equal to source. Is it correct? Button doesn't seemed have equal sizes.
4. I didn't found how disabled state is drawn for FillIn widget. Should I process it manually or it is processed somewhere else?

I'll let Constantin answer these.

5. When user clicked checkbox - should I sync new state with the server?

No. But the next time the screen buffer is updated, the change should be reflected. For sure the widget should be considered "modified" in response to the click.

Vadim Gindin wrote:

1. When I'm going between checkboxes I've faced with view affect (see attached image). Why it can happen?

Vadim, I have some other fixes related to ghosting in a pending update, so don't try to fix this now.

3. I tried to draw objects with sizes equal to source. Is it correct? Button doesn't seemed have equal sizes.

I don't understand this question. Do you refer to the label's size or the actual checkbox size? More, what happens if you change the WIDTH/HEIGHT-CHARS/PIXELS attributes for the checkbox?

4. I didn't found how disabled state is drawn for FillIn widget. Should I process it manually or it is processed somewhere else?

When drawing a FILL-IN in GUI, I'm checking if is enabled, not disabled. There is a AbstractWidget.isEnabled API which tells you the state of the widget (sensitive or not). Depending on the value returned by this API, your code will draw the widget either in a sensitive/enabled state or in a disabled state. More, you need to check if there are any drawing differences when focus is owned by the checkbox. If so, use the AbstractWidget.hasFocus to determine if the widget currently has focus or not.

Greg Shah wrote:

..

2. How to calculate real colors for checkbox lines? I just try them intuitively.

This should be defined by one of the Windows system colors. The important thing is to determine which one is used in Windows 4GL by changing the system color definitions one at a time and testing to see which one causes the lines to change. The 4GL is using the WIN32 API CreateWindowEx using a BUTTON type and a BS_CHECKBOX "style". The underlying WIN32 control will use one of the system colors for the lines.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms632680%28v=vs.85%29.aspx

..

How can I change some system color, as you advise? I thought that I can do it in Windows Registry and even found a path HKEY_LOCAL_MACHINE\SYSTEM\GWE\SysColor containing a big binary object of 29 DWORD values, each of wich is a color attribute like COLOR_3DLIGHT or COLOR_HIGHLIGHT. Unfortunately I didn't find this path in the customer's Windows Server 2008 system. Probably this path exists only in desktop versions of Windows. More, I'm not sure that my user on the customer's system is able to change such Registry values.

Constantin Asofiei wrote:

..
Vadim Gindin wrote:

3. I tried to draw objects with sizes equal to source. Is it correct? Button doesn't seemed have equal sizes.

I don't understand this question. Do you refer to the label's size or the actual checkbox size? More, what happens if you change the WIDTH/HEIGHT-CHARS/PIXELS attributes for the checkbox?

I meant the following. I installed KRuler (screen ruler application) that days to be able to measure sizes of elements. Using this instrument I made GUI checkboxes of the same size as Progress checkboxes (components itself without labels). I used constants.

By the, your question about WIDTH/HEIGHT-CHARS/PIXELS is for P2J or Progress?

How can I change some system color, as you advise?

Isn't there something in the Control Panel that allows you to edit the system colors?

Vadim Gindin wrote:

Constantin Asofiei wrote:

..
Vadim Gindin wrote:

3. I tried to draw objects with sizes equal to source. Is it correct? Button doesn't seemed have equal sizes.

I don't understand this question. Do you refer to the label's size or the actual checkbox size? More, what happens if you change the WIDTH/HEIGHT-CHARS/PIXELS attributes for the checkbox?

I meant the following. I installed KRuler (screen ruler application) that days to be able to measure sizes of elements. Using this instrument I made GUI checkboxes of the same size as Progress checkboxes (components itself without labels). I used constants.

By the, your question about WIDTH/HEIGHT-CHARS/PIXELS is for P2J or Progress?

These attributes will give you the check-box's dimension in 4GL; what I don't know if this includes only the actual checkbox or the label, too. You can use these and find their correlation with the widget's font or pixels-per-column and pixels-per-row values.

Greg Shah wrote:

How can I change some system color, as you advise?

Isn't there something in the Control Panel that allows you to edit the system colors?

There are just some possibility to customize color scheme but there are no possibility to know what color do you change. The set of available elements to change color in are very short and does not contain checkboxes.

I can't logon to windev01 right now and I don't have easy access to a windows system. But I'm quite sure that you can change the color scheme for the standard windows syscolors. Please do some research and figure out how to do it. Then post the instructions here.

Greg Shah wrote:

I can't logon to windev01 right now and I don't have easy access to a windows system. But I'm quite sure that you can change the color scheme for the standard windows syscolors. Please do some research and figure out how to do it. Then post the instructions here.

1. What concrete color value to use.
2. What constant to use, that indicates such color.

Returning to the customer's Windows system. I can change color scheme or some of appearance colors (but not all) like window title color or others, but I will not know the color constant, denoting concrete color. There are no such possibility in Control Panel interface. The only way is to write some script in Visual Basic using specified instruction.

It is an instruction how to change system colors using Visual Basic.

The code would be simpler to do it in C and use the WIN32 API more directly. However, if you find it easier to use VB, that is OK. Whatever gets the job done quickly.

What concrete color value to use.

You may want to write some code to output the current color settings for the entire set of syscolors. The GetSysColor() API can do this for you.

Then you can pick any color that is very different from the current color being used. It doesn't matter what the color is, so long as you can identify the change in the control. For example, bright purple or bright green are probably different enough.

What constant to use, that indicates such color.

This is where the experimentation comes in. You can review the WIN32 API docs for GetSysColor() (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724371%28v=vs.85%29.aspx) which has useful description of the supported system color constants. Start by trying to pick the ones that might be in use.

Then change one of them (and only one at a time) to the bright green or bright purple and then bring up a 4GL app that can show the control. You will pretty quickly be able to determine which system colors are used for the 4GL control.

One other thing to remember: in Windows a toggle-box (or "check-box" in WIN32 terms) is actually a type of WIN32 button control. So the colors in use are likely to be the same ones used for buttons.

Here is the following result of WIN32 API calls:
8 - COLOR_WINDOWTEXT – the color of the "check" and the color of the label
20 - COLOR_3DHIGHLIGHT - the color of the toggle-box border
21 - COLOR_3DDKSHADOW – the color of the toggle-box border shadow.

Here is the colors defined using KRuler:
BOTTOM and RIGTH: #D6D3CE
LEFT and TOP: #424142 and #848284

Here is the result of attributes testing (WIDTH-CHARS/PIXELS, HEIGHT-CHARS/PIXELS):
WIDTH-CHARS: 8.6
WIDTH-PIXELS: 43 (it looks like it includes label)
WIDTH: 8.6
HEIGHT-CHARS: 0.81
HEIGHT-PIXELS: 17

These values are different than H/W measured by KRuler:
WIDTH: 6px
HEIGHT: 12px

Why it is different?

Vadim Gindin wrote:

Here is the following result of WIN32 API calls:
8 - COLOR_WINDOWTEXT – the color of the "check" and the color of the label
20 - COLOR_3DHIGHLIGHT - the color of the toggle-box border
21 - COLOR_3DDKSHADOW – the color of the toggle-box border shadow.

Here is the colors defined using KRuler:
BOTTOM and RIGTH: #D6D3CE
LEFT and TOP: #424142 and #848284

Here is the result of attributes testing (WIDTH-CHARS/PIXELS, HEIGHT-CHARS/PIXELS):
WIDTH-CHARS: 8.6
WIDTH-PIXELS: 43 (it looks like it includes label)
WIDTH: 8.6
HEIGHT-CHARS: 0.81
HEIGHT-PIXELS: 17

These values are different than H/W measured by KRuler:
WIDTH: 6px
HEIGHT: 12px

Why it is different?

Check the dimension using a frame with NO-LABELS clause/widget with NO-LABEL, to find if the height is linked to the label's font or not. Also, set the BGCOLOR/FGCOLOR attributes to see exactly the area occupied by the widget - this is what you need to measure to determine the widget's dimension. The inner check-box may have some metrics independent of the widget's real size (which is used when performing the frame layout and so on).

Set the widget's height/width explicitly: does this affect the check-box? If not, then we can assume this is constant (or maybe dependent on some windows setting - i.e. border width, etc). Ensure the widget is drawn correctly, in respect to its 4GL dimension.

That was my procedure:

def var logic as logical init true.
def var varother as logical init ?.
def var tbx as handle.
def button exit_btn label "exit".

def frame f skip(1) exit_btn no-labels.

create toggle-box tbx
  assign 
  name = "tbx" 
  visible = true
  sensitive = true
  bgcolor = 4
  /*width = 10
  height = 1.6*/
  frame = frame f:handle.

display logic view-as toggle-box with no-labels frame f.
display varother view-as toggle-box with frame f.

message "name: " + tbx:name + "width-chars: " + string(tbx:width-chars) +
        "width-pixels: " + string(tbx:width-pixels) + "width: " + string(tbx:width) + 
        "height-chars: " + string(tbx:height-chars) + "height-pixels: " + string(tbx:height-pixels) +
        "height: " + string(tbx:height).

enable all with frame f.

wait-for choose of exit_btn.

Vadim Gindin wrote:

After I set BGCOLOR I saw real area, occupied by widget and when I manually changed width and size this area was also changed whereby checkbox are stayed the same, so let assume that it has constant dimension. See attached pics.

OK, we can assume the checkbox has constant size for now. But note how it is drawn - is it centred vertically? What about horizontal position: is this fixed?

Several questions.

1. That area, occupied by widget - where it is managed? I only draw a checkbox and it's label in the ToggleBox.draw() method.

The area needs to be managed by your ToggleBox widget, too. If you set the BGCOLOR/FGCOLOR, then P2J needs to behave the same. The 4GL TOGGLE-BOX widget is composed from the check-box, which is drawn (vertically centered?) in a certain rectangle, which is part of the widget, too. BTW, is the toggle-box's label draw within the widget or separately?

1. How WIDTH-CHARS/HEIGHT-CHARS are calculated. For example h=0.81. Does it really mean 81% of the height of analogical area occupied by one character?

The WIDTH/HEIGHT-CHARS are computed using its WIDTH/HEIGHT-PIXELS attributes divided by the SESSION's PIXELS-PER-COLUMN/ROW attributes.

1. I probably should check that described attributes contain the same values in p2j implementation. Isn't it?

Yes, these values should match.

Code Review vig_upd20150501a.zip

It is a very good start.

1. In ToggleBoxGuiImpl.draw(), the 3 TODOs should be fixed based on the similar locations in ButtonGuiImpl. The clipping in that class has been implemented properly.

2. The ToggleBoxGuiImpl P2J imports should use wildcards. DO NOT use wildcards for the java.awt. imports since it will make those easier to remove later. My current work is about removing all AWT/Swing dependencies from common GUI code like ToggleBoxGuiImpl, so I will have to deal with that later.

3. The GuiWidgetFactory needs a history entry.

I'm working on WIDTH/HEIGHT attributes and after the last update this attributes became 0. Don't you know why? And where it is set? I found 2 places: BaseEntity, SyncCoordinatesAspect, but none of the was called during my testcase:

def var tbx as handle.
def button exit_btn label "exit".

def frame f skip(1) exit_btn no-labels.

create toggle-box tbx
  assign
  name = "tbx" 
  visible = true
  sensitive = true
  bgcolor = 4
  /*width = 10
  height = 1.6*/
  frame = frame f:handle.

message "name: " + tbx:name + " width-chars: " + string(tbx:width-chars) +
        " width-pixels: " + string(tbx:width-pixels) + " width: " + string(tbx:width) +
        " height-chars: " + string(tbx:height-chars) + " height-pixels: " + string(tbx:height-pixels) +
        " height: " + string(tbx:height).

enable all with frame f.

wait-for choose of exit_btn.

Just for documenting purpose. This testcase also shows wrong placement of toggle-box. Progress shows toggle-box at the first row and the button "exit" at the second row, but P2J shows both on the second row and button is first.

Addition to previous note. If I'll remove skip(1) expression from the frame definition, than Progress will show toggle-box right over the button, but P2J will show toggle-box after the button in one row.

Vadim Gindin wrote:

Addition to previous note. If I'll remove skip(1) expression from the frame definition, than Progress will show toggle-box right over the button, but P2J will show toggle-box after the button in one row.

Can you please check a test which uses a static toggle-box, not a dynamic one? Use a logical var and a VIEW-AS TOGGLE-BOX phrase.

Static case works fine: both P2J and Progress shows toggle-box in one row after the button "exit".

If user presses mouse on checkbox and starts dragging the mouse over it checkbox background is colored to some other gray color until the mouse pointer is moved over the border of toggle-box. So I need to process mouse events and redraw checkbox background.

How to process mouse dragging event? It is not saved in config. I.e. there are no corresponding attributes in config classes. I can override AbstractWidget.mouseDragged(MouseEvent) and post repaint event and than during draw method execution I need to understand dragging state to correctly choose checkbox background color?

I've checked attributes and events. P2J works as Progress. VALUE-CHANGED event is not working for both Progress and P2J. MANUAL-HIGHLIGHT attribute is not implemented. Others attributes and events works fine. Most of all. What should be implemented to the end of this week: what did I miss except WIDTH/HEIGHT attributes and some draw peculiarities?

The 4GL docs say that VALUE-CHANGED should work. Make sure that your testcase is correct. That event is probably very important.

Please write the list of other events you have tried. Triggers on those events are working?

Have you checked code that does an UPDATE on a static widget to make sure that the logical variable is modified as expected?

Have you checked ENABLE + WAIT-FOR and then tested both ASSIGN (for static widgets) and SCREEN-VALUE (for both static and dynamic widgets) to make sure that the value is updated?

Have you tried different layout and sizing options?

Have you tried different colors and fonts?

Have you checked that focus processing is working?

Vadim Gindin wrote:

If user presses mouse on checkbox and starts dragging the mouse over it checkbox background is colored to some other gray color until the mouse pointer is moved over the border of toggle-box. So I need to process mouse events and redraw checkbox background.

Are you describing the 4GL behavior here?

Greg Shah wrote:

Vadim Gindin wrote:

If user presses mouse on checkbox and starts dragging the mouse over it checkbox background is colored to some other gray color until the mouse pointer is moved over the border of toggle-box. So I need to process mouse events and redraw checkbox background.

Are you describing the 4GL behavior here?

Yes.

Greg Shah wrote:

The 4GL docs say that VALUE-CHANGED should work. Make sure that your testcase is correct. That event is probably very important.

You are right about VALUE-CHANGED. It works. It was just overriden by low-level mouse events. I retested it and fixed P2J. But I've found that some mouse events (MOUSE-SELECT-CLICK, LEFT-MOUSE-CLICK) do not allow it to work. I.e. when there are triggers defined for VALUE-CHANGED event and for one of these 2 events simultaneously, than trigger for mouse event is called, but VALUE-CHANGED event is not called. I didn't implemented it at this moment.

Please write the list of other events you have tried. Triggers on those events are working?

I tested following events list:
ENTRY works
LEAVE works
VALUE-CHANGED works
LEFT-MOUSE-CLICK works
RIGHT-MOUSE-DOWN/UP works
MOUSE-SELECT-CLICK works
developer event U1 works
"General Direct Manipulation Events" such as START-MOVE, SELECTION. not work.
ENDKEY couldn't test. When I press ESC - window is closed immediately, without any pause.
GO trigger is not called.
RETURN works.

Legacy mouse events will probably need additional testing because there some complex processing logic.. I faced with it first time.

Have you checked code that does an UPDATE on a static widget to make sure that the logical variable is modified as expected?

No. I will.

Have you checked ENABLE + WAIT-FOR and then tested both ASSIGN (for static widgets) and SCREEN-VALUE (for both static and dynamic widgets) to make sure that the value is updated?

I'm not sure I understand what do you mean. Have a look in my testcase:

def var logic as logical.
def var varother as logical.

def button exit_btn label "exit".

def frame f skip exit_btn.

assign  logic = true.

display logic view-as toggle-box with frame f.
display varother view-as toggle-box with frame f.

varother:screen-value = "yes".

message logic:screen-value.

enable all with frame f.

wait-for choose of exit_btn.

This test works fine (P2J like Progress). both toggle-boxes are checked and message area contains the string "yes".
Is it what you mean?

Have you tried different layout and sizing options?

1. There is layout bug documented earlier for dynamic toggle-box. See note №35. Dynamic togglebox is drawn after the button in P2J and right over the button in Progress.
2. There is a view artifact described in the not №14 - extra checkbox is drawn over the window title.
3. Some changes will needed to be implemented for non-default size of toggle-box (checkbox is centered vertically).

What layout options can I test?

Have you tried different colors and fonts?

Yes, I've fixed font setting.

Have you checked that focus processing is working?

Yes, I've fixed focus gaining when user clicks toggle-box.

This test works fine (P2J like Progress). both toggle-boxes are checked and message area contains the string "yes".

Is it what you mean?

Almost. The thing that is missing is testing that an ASSIGN or SCREEN-VALUE AFTER the WAIT-FOR will work properly.

What layout options can I test?

Test the TO, AT and COLON format phrase options. If you find issues, post them here and we will discuss their priority.

Priority order (do as much as you can):

1. Make sure UPDATE works.
2. Make sure ASSIGN and SCREEN-VALUE after WAIT-FOR work.
3. Fix the extra checkbox drawn over the window title.
4. Fix the WIDTH/HEIGHT calculation.
5. Fix the dynamic togglebox drawn after the button in P2J and right over the button in Progress.
6. Fix the non-default size of toggle-box (checkbox is centered vertically).
7. Fix the mixing of mouse events (MOUSE-SELECT-CLICK, LEFT-MOUSE-CLICK) with VALUE-CHANGED.

For sizing and layout issues, ask Hynek help as needed but use the task history here to document the discussion.

It is important to stabilize the changes and get them checked in before end of day Friday.

Code Review vig_upd20150506a.zip

I'm OK with the code so far.

Since MAJIC doesn't use toggle-boxes and your change to Key.java is safe, as of now your code will not need regression testing. If you need to make changes in common code or ChUI code, then regression testing will be needed.

In regard to the WIDTH/HEIGHT issue, Hynek reported the following:

I tested your sample. The problem doesn't seem to be a regression in my update. The reason why zero sizes are reported in the MESSAGE statement is that the client widget doesn't set the config's widthPixels and heightPixels. The logic of populating config.widthPixels is there in one of the toggle box's constructor, it's just not called.

Also note that button widget (which seems to be the source of inspiration for the toggle box) also doesn't set config.heightPixels and so its HEIGHT-CHARS/HEIGHT-PIXELS legacy attributes are zero. This applies for trunk as well as version before my suspected update. This is wrong and should be fixed.

It is the responsibility of the client widget to set config.widthPixels/heightPixels with meaningful default values and update the values when its state changes (for example label changes) and size is not explicitly set.

Please do apply your WIDTH/HEIGHT fix to button as well.

There is a strange thing with UPDATE statement for toggle-box. Have a look at this procedure:

def var i as logical.
/* display i view-as toggle-box with frame f. */
message "before: " + string(i).
update i with frame f.
message "after: " + string(i).
wait-for go of frame f.

This variant is working, but the field is displayed as FillIn with 2 possible values "yes" and "no". I'm changing its value and press ENTER and the message "after ..." appears in the message area.

If I'll display variable as toggle-box (see commented line), than execution stops at update statement and the last message statement is not executed.

P.S.
I'm recalling that GO event does not work for toggle-box. A trigger for that event will not be called. So when checkbox is displayed and I press Enter nothing is happen. I suspect that it is related to UPDATE statement somehow.

Am I right?

This testcase doesn't seem correct. In the 4GL, the UPDATE statement is roughly equivalent to ENABLE + WAIT-FOR + ASSIGN. And we have strived to duplicate this.

This variant is working, but the field is displayed as FillIn with 2 possible values "yes" and "no". I'm changing its value and press ENTER and the message "after ..." appears in the message area.

The ENTER is occurring inside the UPDATE statement and it generates a GO event. The hidden ASSIGN occurs and then the MESSAGE executes, seeing the modified var i contents.

At that point, the WAIT-FOR is encountered, but there are no enabled widgets so I would expect that to cause an error. The WAIT-FOR should not be part of this testcase.

If I'll display variable as toggle-box (see commented line), than execution stops at update statement and the last message statement is not executed.

What do you mean by "stops at update statement"?

Even without the toggle-box, the processing stops at the UPDATE because there is a hidden WAIT-FOR inside the UPDATE.

I'm recalling that GO event does not work for toggle-box. A trigger for that event will not be called.

Is this in the 4GL or P2J?

I expect that the 4GL should work fine. If P2J is a problem, then it needs to go on the list to be fixed.

Am I right?

I don't know. I do wonder if this is a similar problem that Eugenie saw recently with the button widget in GUI. Where a button as the last enabled widget did not properly handle GO. See bzr rev 10832 which is where he made some fixes.

You can swap the UPDATE for a ENABLE + WAIT-FOR + ASSIGN to see if the problem is the same.

Greg Shah wrote:

This testcase doesn't seem correct. In the 4GL, the UPDATE statement is roughly equivalent to ENABLE + WAIT-FOR + ASSIGN. And we have strived to duplicate this.

This variant is working, but the field is displayed as FillIn with 2 possible values "yes" and "no". I'm changing its value and press ENTER and the message "after ..." appears in the message area.

The ENTER is occurring inside the UPDATE statement and it generates a GO event. The hidden ASSIGN occurs and then the MESSAGE executes, seeing the modified var i contents.

At that point, the WAIT-FOR is encountered, but there are no enabled widgets so I would expect that to cause an error. The WAIT-FOR should not be part of this testcase.

If I'll display variable as toggle-box (see commented line), than execution stops at update statement and the last message statement is not executed.

What do you mean by "stops at update statement"?

I mean that the last message "after .." is not printed, i.e. execution is stopped before this statement.

Even without the toggle-box, the processing stops at the UPDATE because there is a hidden WAIT-FOR inside the UPDATE.

I'm recalling that GO event does not work for toggle-box. A trigger for that event will not be called.

Is this in the 4GL or P2J?

I expect that the 4GL should work fine. If P2J is a problem, then it needs to go on the list to be fixed.

Yes, that is about 4GL. Here is the simplest test:

def var lll as logical.

display lll view-as toggle-box with frame f. 

on go of lll
  message "go".

enable all with frame f.
wait-for close of current-window.

The trigger is not called.

I mean that the last message "after .." is not printed, i.e. execution is stopped before this statement.

The program ends?

Or does the program wait for user input?

def var lll as logical.

display lll view-as toggle-box with frame f. 

on go of lll
  message "go".

enable all with frame f.
wait-for close of current-window.

This is incorrect. GO is a frame-level event. Try on go of frame f instead of on go of lll will not.

Greg Shah wrote:

I mean that the last message "after .." is not printed, i.e. execution is stopped before this statement.

The program ends?

Or does the program wait for user input?

The program does not end. Nothing happen. Probably, it waits for input..

[...]

This is incorrect. GO is a frame-level event. Try on go of frame f instead of on go of lll will not.

I've tried. Trigger is not called.

"2. Make sure ASSIGN and SCREEN-VALUE after WAIT-FOR work."

I've checked. P2J works as 4GL. Here is my test case:

def var logic as logical.
def var varother as logical.

def button exit_btn label "exit".

def frame f skip exit_btn.

display logic view-as toggle-box with frame f.
display varother view-as toggle-box with frame f.

enable all with frame f.
wait-for choose of exit_btn.

assign  logic = true.
varother:screen-value = "yes".

message logic:screen-value + ": " + string(logic).
message varother:screen-value + ": " + string(varother).

Is it correct?

"3. Fix the extra checkbox drawn over the window title."
Constantin wrote me in the note №16: "Vadim, I have some other fixes related to ghosting in a pending update, so don't try to fix this now.". So it is not fixed yet.. Should I work on it now anyway?

This is incorrect. GO is a frame-level event. Try on go of frame f instead of on go of lll will not.

I've tried. Trigger is not called.

Try pressing F1 or whatever key is that is mapped to the GO event in GUI.

Is it correct?

No.

def var logic as logical.
def var varother as logical.

def button exit_btn label "exit".

def frame f skip exit_btn.

display logic view-as toggle-box
        varother view-as toggle-box with frame f.

enable all with frame f.
wait-for choose of exit_btn.

/* this code assigns the current screen-buffer values back to the variables */
assign logic in frame f
       varother in frame f.

/* this code ALSO assigns the current screen-buffer values back to the variables */
/* uncomment this to test
logic = logic:screen-value.
varother = varother:screen-value.
*/

message logic:screen-value + ": " + string(logic).
message varother:screen-value + ": " + string(varother).

So it is not fixed yet.. Should I work on it now anyway?

No.

So it is not fixed yet.. Should I work on it now anyway?

Actually, yes. Constantin's changes are already checked in. If that didn't fix the ghosting, then it is an issue in the toggle box implementation.

Greg Shah wrote:

This is incorrect. GO is a frame-level event. Try on go of frame f instead of on go of lll will not.

I've tried. Trigger is not called.

Try pressing F1 or whatever key is that is mapped to the GO event in GUI.

Is it correct?

No.

[...]

So it is not fixed yet.. Should I work on it now anyway?

No.

I've tested it. It works fine. assign frame f logic.

Greg, thank you! "F2" is mapped on "GO" event in GUI. I've tested GO event. It works for toggle-box. Trigger on go of tbx is called for both 4GL and P2J. I've also tested UPDATE:

def var i as logical.
display i view-as toggle-box with frame f. 
message "before: " + string(i).
update i with frame f.
message "after: " + string(i).

But 4GL clears the window and P2J - does not. Should I fix it?

Do you mean that the frame f is still displayed in P2J but in the 4GL it is made invisible?

Greg Shah wrote:

But 4GL clears the window and P2J - does not. Should I fix it?

Do you mean that the frame f is still displayed in P2J but in the 4GL it is made invisible?

I'm not sure if it is a frame, because frame f:visible is still "yes".

Please post 2 screen captures (of the 4GL and P2J) so I can understand what you mean.

About WIDTH*/HEIGHT* attributes initialization problem. Hynek proposed me to initialize these fields in ToggleBox.initialize() or in ToggleBoxGuiImpl.initialize() method. I'm trying to set WIDTH-CHARS in ToggleBoxGuiImpl.initialize(). Should I just call textLabel().length() to calculate label length in characters as it happen in ToggleBox or I should call something like this gd.getTextWidth(textLabel(), gf.font().font) to take into account current font?

There is the following testing result, that confuse me. I have a test procedure with static toggle-box:

def var tbx as logical.
def button exit_btn label "exit".
def frame f exit_btn no-labels.
display tbx view-as toggle-box with frame f.

tbx:bgcolor = 4.

message "name: " + tbx:name + " width-chars: " + string(tbx:width-chars) +
        " width-pixels: " + string(tbx:width-pixels) + " width: " + string(tbx:width) +
        " height-chars: " + string(tbx:height-chars) + " height-pixels: " + string(tbx:height-pixels) +
        " height: " + string(tbx:height).

pause.

tbx:label = ?.

message "name: " + tbx:name + " width-chars: " + string(tbx:width-chars) +
        " width-pixels: " + string(tbx:width-pixels) + " width: " + string(tbx:width) +
        " height-chars: " + string(tbx:height-chars) + " height-pixels: " + string(tbx:height-pixels) +
        " height: " + string(tbx:height).

enable all with frame f.
wait-for choose of exit_btn.

It prints WIDTH/HEIGHT attributes values twice: when label="tbx" and when label became empty.

At the moment of first message call toggle-box has the label="tbx" and WIDTH-CHARS=7.8
At the moment of the second message call toggle-box has empty label and WIDTH-CHARS=5.

That means label width in characters is 7.8-5=2.8 and label width is not just a number of characters. Am I right?

So I made conclusion of necessity to take into account used font. There is the problem in GuiFontResolver.font(). It use widget config to get font number and this config is not initialized at that moment.

So, How to correctly calculate label width in widget?

About the window clearing, I don't think this has anything to do with the toggle-box. We will work it in another task.

Greg Shah wrote:

About the window clearing, I don't think this has anything to do with the toggle-box. We will work it in another task.

Thank you.

About label width for widgets: gd.getTextWidth("tbx", gf.font().font) has returned 13. Is it in pixels or characters?

Vadim Gindin wrote:

About WIDTH*/HEIGHT* attributes initialization problem. Hynek proposed me to initialize these fields in ToggleBox.initialize() or in ToggleBoxGuiImpl.initialize() method. I'm trying to set WIDTH-CHARS in ToggleBoxGuiImpl.initialize(). Should I just call textLabel().length() to calculate label length in characters as it happen in ToggleBox or I should call something like this gd.getTextWidth(textLabel(), gf.font().font) to take into account current font?

There is the following testing result, that confuse me. I have a test procedure with static toggle-box:
[...]

It prints WIDTH/HEIGHT attributes values twice: when label="tbx" and when label became empty.

At the moment of first message call toggle-box has the label="tbx" and WIDTH-CHARS=7.8
At the moment of the second message call toggle-box has empty label and WIDTH-CHARS=5.

That means label width in characters is 7.8-5=2.8 and label width is not just a number of characters. Am I right?

So I made conclusion of necessity to take into account used font. There is the problem in GuiFontResolver.font(). It use widget config to get font number and this config is not initialized at that moment.

So, How to correctly calculate label width in widget?

Please look into LabelGuiImpl.nativeWidth and how GuiFontResolver is used. Basically, you need to call FontManager.getTextWidth(<the-label-text>, window, font, gd); to compute the label's width in native units and after that use CoordinateConversion to convert it to character units (see Label.updateSize for an example).

Also, to match the label's metrics on windev01, you need to retrieve the legacy text metrics from windev01. I'll come back with another post how to do that.

Vadim Gindin wrote:

About label width for widgets: gd.getTextWidth("tbx", gf.font().font) has returned 13. Is it in pixels or characters?

This always returns pixels.

In looking at your screen-shots, is the P2J toggle-box shadow color correct? It seems too dark.

1. After each conversion, there is a file named ui_strings.txt which contains the texts for which legacy metrics are needed. Copy this file on windev01.
2. Copy the entire tools/ folder from the P2J project to windev01.
3. start the get-text-metrics.p program and specify:
   - the maximum font size (you can leave it to 20 or set it to 10 if you haven't changed the font-table)
   - the file with the font names (font-list.txt)
   - the file with the strings which require metrics (ui-strings.txt)
   - it will take a while to generate, if you have may strings. Note that this needs to be done each time you are changing/adding new tests/ etc to your conversion - otherwise the metrics DB might get "obsolete" and not in sync with what you are testing, and will lead you to incorrect paths.
4. copy the generated text-metrics.xml to your testcases/src folder (or p2j/src if you are generating the sources directly in the p2j folder).

Constantin Asofiei wrote:

About matching the label metrics in GUI with the legacy metrics as on windev01.

1. After each conversion, there is a file named ui_strings.txt which contains the texts for which legacy metrics are needed. Copy this file on windev01.
2. Copy the entire tools/ folder from the P2J project to windev01.
3. start the get-text-metrics.p program and specify:
   - the maximum font size (you can leave it to 20 or set it to 10 if you haven't changed the font-table)
   - the file with the font names (font-list.txt)
   - the file with the strings which require metrics (ui-strings.txt)
   - it will take a while to generate, if you have may strings. Note that this needs to be done each time you are changing/adding new tests/ etc to your conversion - otherwise the metrics DB might get "obsolete" and not in sync with what you are testing, and will lead you to incorrect paths.
4. copy the generated text-metrics.xml to your testcases/src folder (or p2j/src if you are generating the sources directly in the p2j folder).

Constantin, I did it, generate text-metrics.xml and copied it to "/testcases/uast/src" folder. Should I rerun conversion?

I used the code you advised:

      Window<?> window = Window.resolveWindow(this);
      int nativeWidth = FontManager.getTextWidth(textLabel(), window, gf.resolveFontNum(), gd);
      CoordinatesConversion coordinates = screen().coordinates();
      config.widthChars = coordinates.widthFromNative(nativeWidth) + getCheckboxWidth(); 

nativeWidth became 13 and coordinates.widthFromNative(nativeWidth) became 2.6, And that was not changed after I placed generated text-metrics to "testcases/uast/src@.

Questions.
Shouldn't it became 2.8 as it is on windev01?
I reran conversion but it didn't help. What should I do to get 2.8 as it is on windev01?

Vadim Gindin wrote:

Constantin Asofiei wrote:

About matching the label metrics in GUI with the legacy metrics as on windev01.

1. After each conversion, there is a file named ui_strings.txt which contains the texts for which legacy metrics are needed. Copy this file on windev01.
2. Copy the entire tools/ folder from the P2J project to windev01.
3. start the get-text-metrics.p program and specify:
   - the maximum font size (you can leave it to 20 or set it to 10 if you haven't changed the font-table)
   - the file with the font names (font-list.txt)
   - the file with the strings which require metrics (ui-strings.txt)
   - it will take a while to generate, if you have may strings. Note that this needs to be done each time you are changing/adding new tests/ etc to your conversion - otherwise the metrics DB might get "obsolete" and not in sync with what you are testing, and will lead you to incorrect paths.
4. copy the generated text-metrics.xml to your testcases/src folder (or p2j/src if you are generating the sources directly in the p2j folder).

Constantin, I did it, generate text-metrics.xml and copied it to "/testcases/uast/src" folder. Should I rerun conversion?

I used the code you advised:
[...]

nativeWidth became 13 and coordinates.widthFromNative(nativeWidth) became 2.6, And that was not changed after I placed generated text-metrics to "testcases/uast/src@.

Questions.
Shouldn't it became 2.8 as it is on windev01?
I reran conversion but it didn't help. What should I do to get 2.8 as it is on windev01?

1. did text-metrics.xml end up in your classpath (i.e testcases.jar, p2j.jar ?) Do idea is: after you place it in src/ you either rebuild your testcases project or refresh your IDE project, so this file is included in the classpath.
2. what progress.ini are you using on windev01? If you are using the default one, then check your directory.xml - if there is a font-table node, then rename it to font-table-not-used, so that P2J uses the standard font table ,too

Thank you! It was a classpath problem. I had "/testcases/uast/font/system.metrics" folder in my classpath and after I removed it I got 2.8.

Hynek:

I think afterConfigUpdate is in your case called from "apply config" call and afterSetWidthPixels() is exited before chars are converted. You can confirm this by placing a break point at the beginning of afterSetWidthPixels(), the method should get called on client.

The "apply config" check is probably too restrictive here. As a workaround I suggest you do the conversion by hand (replicating what afterSetWidthPixels() does) and put a TODO there mentioning that the conversion should be performed by SyncCoordinatesAspect.

Vadim:

Another one question. I'm setting toggle-box label from server-side and I'm recalculating config.widthChars in the afterConfigUpdate(..) method when label was changed. The problem is that SyncCoordinatesAspect.afterSetWidthChars(..) is not called here to set widthPixels. Do you know why it isn't called?

I've fixed it. Sorry to trouble.

Vadim Gindin wrote:

I've fixed it. Sorry to trouble.

What was the problem?

There is a change in rev 10849 ThinClient, which addresses a focus lost issue - please check if that doesn't fix your problem, too.

Vadim Gindin wrote:

Constantin Asofiei wrote:

Vadim Gindin wrote:

I've fixed it. Sorry to trouble.

What was the problem?

There is a change in rev 10849 ThinClient, which addresses a focus lost issue - please check if that doesn't fix your problem, too.

The problem was in the circumstance, that refresh() method was called, containing direct draw() call. refresh() method was called when checkbox was clicked. I'm not sure exactly why, but I replaced it with repaint() call and it works now.

OK, you are talking about AbstractButton.refresh, correct? And your change, is it in your GUI impl class or in some other class? Because I see this code is being used for the GUI BUTTON too, and calling draw without a translated origin will pose problems.

I have 2 layout problems:

1. Dynamically created toggle-box is layout right over button in 4GL. P2J shows it after the button. I wrote about it in the note 35.

I think this might not be related only to toggle-box; instead, I think we should postpone this to a distinct task, to confirm/fix the layout when dynamic widgets are used. So is best to focus now only on the static version.

1. There is some shift between button and toggle-box. See attached image.

Either there is a layout problem or the button's width is not computed correct. So, first use bgcolor/fgcolor on the button to determine its boundaries and we will continue from there.

So, I don't know where frame components placement happen. How the toggle-box position is calculated. Could you advice me where to find it?

If you are referring to the position of the toggle-box's inner "check-box" and its associated label, then this is the responsibility of your GUI impl class - if these were two different widgets, then the layout would have been in the ZeroColumnLayout. So, when drawing, ensure that both the associated label and the inner checkbox are drawn in the correct place: use the TOGGLE-BOX's height to vertically center the check-box and the label.

Constantin Asofiei wrote:

Vadim Gindin wrote:

Constantin Asofiei wrote:

Vadim Gindin wrote:

I've fixed it. Sorry to trouble.

What was the problem?

There is a change in rev 10849 ThinClient, which addresses a focus lost issue - please check if that doesn't fix your problem, too.

The problem was in the circumstance, that refresh() method was called, containing direct draw() call. refresh() method was called when checkbox was clicked. I'm not sure exactly why, but I replaced it with repaint() call and it works now.

OK, you are talking about AbstractButton.refresh, correct? And your change, is it in your GUI impl class or in some other class? Because I see this code is being used for the GUI BUTTON too, and calling draw without a translated origin will pose problems.

I changed the method check() that inverts state and redraws toggle-box. This method is common for base class ToggleBox and ToggleBoxGuiImpl. I don't have other draw calls in GUI implementation.

I have 2 layout problems:

1. Dynamically created toggle-box is layout right over button in 4GL. P2J shows it after the button. I wrote about it in the note 35.

I think this might not be related only to toggle-box; instead, I think we should postpone this to a distinct task, to confirm/fix the layout when dynamic widgets are used. So is best to focus now only on the static version.

OK.

1. There is some shift between button and toggle-box. See attached image.

Either there is a layout problem or the button's width is not computed correct. So, first use bgcolor/fgcolor on the button to determine its boundaries and we will continue from there.

I've tried to set these attributes for the static button, but no visible changes happen.

So, I don't know where frame components placement happen. How the toggle-box position is calculated. Could you advice me where to find it?

If you are referring to the position of the toggle-box's inner "check-box" and its associated label, then this is the responsibility of your GUI impl class - if these were two different widgets, then the layout would have been in the ZeroColumnLayout. So, when drawing, ensure that both the associated label and the inner checkbox are drawn in the correct place: use the TOGGLE-BOX's height to vertically center the check-box and the label.

I meant a checkbox not as a different widget from P2J point - just as a part of toggle-box widget view. I.e. ZeroColumnLayout is the class that responsible to calculate specific widget position for each widget in frame?

Vadim Gindin wrote:

I've tried to set these attributes for the static button, but no visible changes happen.

OK, so the problem I don't think is the button.

So, I don't know where frame components placement happen. How the toggle-box position is calculated. Could you advice me where to find it?

If you are referring to the position of the toggle-box's inner "check-box" and its associated label, then this is the responsibility of your GUI impl class - if these were two different widgets, then the layout would have been in the ZeroColumnLayout. So, when drawing, ensure that both the associated label and the inner checkbox are drawn in the correct place: use the TOGGLE-BOX's height to vertically center the check-box and the label.

I meant a checkbox not as a different widget from P2J point - just as a part of toggle-box widget view. I.e. ZeroColumnLayout is the class that responsible to calculate specific widget position for each widget in frame?

Yes, ZCL is responsible for layout. See ZCL.getNumSpaces, I think this might be the problem.

Vadim Gindin wrote:

Thank you. Here are my next 2 current layout bugs:

1. After I dynamically reset toggle-box label to ? 4GL automatically shrinks toggle-box layout, but frame layout is stayed untouched. P2J shrinks both. Where is the place where it happen?
2. I faced with extra toggle-box over the window title again. When I'm navigating from button to toggle-box and back using TAB. The reason is in using refresh() in AbstractButton.prevFocus() and AbstractButton.nextFocus(). Can I changed it to repaint()? in all methods in AbstractButton where it is used?

I've found that in ButtonGuiImpl the method refresh() is overridden itself to call repaint, so I'll just do the same. The first question is remained.

Vadim Gindin wrote:

Thank you. Here are my next 2 current layout bugs:

1. After I dynamically reset toggle-box label to ? 4GL automatically shrinks toggle-box layout, but frame layout is stayed untouched. P2J shrinks both. Where is the place where it happen?

P2J does some unnecessary re-layout... again, leave this for now as is. We'll add it to a new task.

What do you have left to do for this first pass?

Code Review vig_upd20150509a.zip

1. Is your ZeroColumnLayout change safe for ChUI?

2. Please remove the src/text-metrics.xml from the update.

3. Is the highlight fixed or are you still working on it?

Greg Shah wrote:

Code Review vig_upd20150509a.zip

1. Is your ZeroColumnLayout change safe for ChUI?

I had no possibility to run testing because I did this change only about 2 hrs ago.

2. Please remove the src/text-metrics.xml from the update.

OK.

3. Is the highlight fixed or are you still working on it?

I'm working on it.

Vadim Gindin wrote:

Greg Shah wrote:

Code Review vig_upd20150509a.zip

1. Is your ZeroColumnLayout change safe for ChUI?

I had no possibility to run testing because I did this change only about 2 hrs ago.

MAJIC doesn't use toggleboxes at all (I've grep'ed through the generated sources and there is no occurrence of ToggleBoxWidget string). So it's safe for MAJIC and no automatic testing is needed for this change.

Please check the toggle-box tests in ChUI and if they work OK, then the change is OK for ChUI.

Code Review vig_upd20150509b.zip

In ToggleBoxGuiImpl, please change CHKBOX_WIDHT to CHKBOX_WIDTH. Otherwise I'm OK with this.

Please document (here) the list of open issues to be finished and/or resolved.

Of great importance is ensuring that the size of the toggle box is always calculated correctly. There is some very useful discussion of how to determine this that can be seen in the #2546 combo-box task. The useful parts start at note 92.

Do you have the list prepared? Please post it.

Also, since this is to be the second check-in for this task, the branch should be 2513b.

Greg Shah wrote:

Do you have the list prepared? Please post it.

I haven't it yet. I tried to dig into size equality issue. Could you specify, what do you expect for me to do:

1. Collect font metrics
2. Collect sizes information for toggle-box for different widths and so on as for combo-box
3. Write a formula of width calculation for toggle-box and implement it

Did I understand you right?

Did I understand you right?

Roughly. Follow the process as described in #2546-98 except you should adapt it to toggle-box.

I'm trying to run (GUI) simple test:

def var tbx as handle.
def button exit_btn label "exit".

def frame ff skip(1) exit_btn no-labels.
def var tbx as handle.
def button exit_btn label "exit".

def frame ff skip(1) exit_btn no-labels.

And I got the error:

com.goldencode.p2j.net.SilentUnwindException: Connection ended abnormally
    at com.goldencode.p2j.net.InvocationStub.invoke(InvocationStub.java:102)
    at com.sun.proxy.$Proxy4.standardEntry(Unknown Source)
    at com.goldencode.p2j.main.ClientCore.start(ClientCore.java:277)
    at com.goldencode.p2j.main.ClientCore.start(ClientCore.java:100)
    at com.goldencode.p2j.main.ClientDriver.start(ClientDriver.java:201)
    at com.goldencode.p2j.main.CommonDriver.process(CommonDriver.java:398)
    at com.goldencode.p2j.main.ClientDriver.process(ClientDriver.java:95)
    at com.goldencode.p2j.main.ClientDriver.main(ClientDriver.java:267)
Caused by: java.lang.IllegalStateException: Widget  4 is not attached to a Window instance.
    at com.goldencode.p2j.ui.client.widget.AbstractWidget.window(AbstractWidget.java:255)
    at com.goldencode.p2j.ui.client.UiUtils.getFramesAbove(UiUtils.java:711)
    at com.goldencode.p2j.ui.chui.ThinClient.selectiveDisable(ThinClient.java:12105)
    at com.goldencode.p2j.ui.chui.ThinClient.destroyFrame(ThinClient.java:12071)
    at com.goldencode.p2j.ui.chui.ThinClient.markFrames(ThinClient.java:10058)
    at com.goldencode.p2j.ui.chui.ThinClient.applyChanges(ThinClient.java:11904)
    at com.goldencode.p2j.net.Protocol.applyChanges(Protocol.java:309)
    at com.goldencode.p2j.net.Dispatcher.processInbound(Dispatcher.java:624)
    at com.goldencode.p2j.net.Conversation.block(Conversation.java:319)
    at com.goldencode.p2j.net.Conversation.waitMessage(Conversation.java:257)
    at com.goldencode.p2j.net.Queue.transactImpl(Queue.java:1128)
        ...

Branch 2513b. Does it known error?

Widget 4 is a frame.

Does it known error?

I have not seen it before, but we have had many regressions in GUI recently so this may be one of them. The testcase is a bit strange since it doesn't use the frame at all. I'm surprised that destroyFrame() is called for a frame that was never used.

I had a test, that dynamically creates toggle-box in specified frames, but when I faced with that error I've removed toggle-box creation to simplify error reproducing.

I'll add this to the list of open issues.

Can you continue your work without this being fixed?

Yes, I can some time.

I've committed gathered toggle-box metrics. There are no possibility to set specific font for toggle-box, so I deleted this parameter from procedures. I don't understand the step, described in the #2546 note 98 about excel. Have a look please.

I don't understand the step, described in the #2546 note 98 about excel.

Your objective is to find the formula that has the best fit to the 4GL sizing behavior. I think the idea with using a spreadsheet is that it can help you analyze your captured data and find that formula.

Vadim, have you tested setting the toggle-box's LABEL? Because the FONT can be set at the TOGGLE-BOX widget, but it affects only its label. From a little testing looks like the "toggle box" image is static in its dimension, and only the label is affected by font. And the widget's implicit width might be computed using a pixels-required-by-the-box-width + label-text-width-using-the-computed-font + any-width-inset-pixels. The height might be just min(font-height, box-pixel-height) + any-height-insets.

Also, after re-capturing the metrics (cases with no label, 1-char label, 2-char label etc) please commit them to the testcases project.

And yes, Greg was correct: in some cases, using a spreadsheet with various metrics to try to determine the formula has helped.

Do /uast/fonts/widget.metrics/courier new/abcdef/3d/toggle-box-metrics.csv values somehow correlate with metrics I'd captured for the same font and if I'd used the same label "abcdef"?

Vadim Gindin wrote:

Do /uast/fonts/widget.metrics/courier new/abcdef/3d/toggle-box-metrics.csv values somehow correlate with metrics I'd captured for the same font and if I'd used the same label "abcdef"?

Ah, I forgot about those. There is a .ods file in there, widget-stats-3d-v2.ods, where there is a spreadsheet with toggle-box metrics imported. Looks like the formula for the pixel width is native-text-width + 25, and for height is native-text-height + 4, with some special consideration when the text height is smaller than the inner box height. So you can go ahead and use that.

Note that you need to compute the pixel width/height and after that the char width/height are computed using the SESSION:PIXELS-PER-COLUMN/ROW values, via the CoordinateConversion APIs.

Constantin Asofiei wrote:

Vadim Gindin wrote:

Do /uast/fonts/widget.metrics/courier new/abcdef/3d/toggle-box-metrics.csv values somehow correlate with metrics I'd captured for the same font and if I'd used the same label "abcdef"?

Ah, I forgot about those. There is a .ods file in there, widget-stats-3d-v2.ods, where there is a spreadsheet with toggle-box metrics imported. Looks like the formula for the pixel width is native-text-width + 25, and for height is native-text-height + 4, with some special consideration when the text height is smaller than the inner box height. So you can go ahead and use that.

Note that you need to compute the pixel width/height and after that the char width/height are computed using the SESSION:PIXELS-PER-COLUMN/ROW values, via the CoordinateConversion APIs.

Or vice versa: compute char width/height and pixel width/height will be recomputed automatically. Isn't it?

I probably should override width()/height() methods or dimension() to set those values. Isn't it?

Vadim Gindin wrote:

Constantin Asofiei wrote:

Vadim Gindin wrote:

Do /uast/fonts/widget.metrics/courier new/abcdef/3d/toggle-box-metrics.csv values somehow correlate with metrics I'd captured for the same font and if I'd used the same label "abcdef"?

Ah, I forgot about those. There is a .ods file in there, widget-stats-3d-v2.ods, where there is a spreadsheet with toggle-box metrics imported. Looks like the formula for the pixel width is native-text-width + 25, and for height is native-text-height + 4, with some special consideration when the text height is smaller than the inner box height. So you can go ahead and use that.

Note that you need to compute the pixel width/height and after that the char width/height are computed using the SESSION:PIXELS-PER-COLUMN/ROW values, via the CoordinateConversion APIs.

Or vice versa: compute char width/height and pixel width/height will be recomputed automatically. Isn't it?

I probably should override width()/height() methods or dimension() to set those values. Isn't it?

1. you really need to compute the pixel dimension first and after that the character dimensions, as the character dimension is computed using the DEFAULT-FONT, and NOT the widget's current font.
2. width/height need to check if the widget's size is set explicitly via the attributes; if so, use that. There are the BaseConfig.fixedWidth and fixedHeight APIs.

In regard to the abend in note 96:

1. I have committed this as testcases/uast/missing_window_attachment.p.
2. The abend is resolved by Constantin's changes in task branch 1811r revision 10948.

I've committed some changes. I think, at this moment common layout width is calculated not correctly. I used /uast/toggle-box/gui/tbx_static.p procedure. There are simple button and toggle-box. The frame is drawn little shorter than it should be and horizontal scrollbar is shown. May be it because of some space between button and toggle-box. Please have a look.

If you want to check widget dimensions, please check the WIDTH/HEIGHT-CHARS and WIDTH/HEIGHT-PIXELS attributes for the button/toggle-box/frame in 4GL and P2J. If they are the same, then this is a drawing issue most likely.

Constantin Asofiei wrote:

If you want to check widget dimensions, please check the WIDTH/HEIGHT-CHARS and WIDTH/HEIGHT-PIXELS attributes for the button/toggle-box/frame in 4GL and P2J. If they are the same, then this is a drawing issue most likely.

They are the same. It probably layout drawing issue, isn't it?

I've found that size 15 by 1.5 clause isn't supported. How it should be supported? Is it a responsibility of toggle-box or layout?

Vadim Gindin wrote:

Constantin Asofiei wrote:

If you want to check widget dimensions, please check the WIDTH/HEIGHT-CHARS and WIDTH/HEIGHT-PIXELS attributes for the button/toggle-box/frame in 4GL and P2J. If they are the same, then this is a drawing issue most likely.

They are the same. It probably layout drawing issue, isn't it?

I've found that size 15 by 1.5 clause isn't supported. How it should be supported? Is it a responsibility of toggle-box or layout?

Either the runtime or the conversion part rounds the 1.5 value to an integer. So this is not specific to toggle-box, but specific to the SIZE option. Please create a separate task for this.

There is some other reason of this ignoring of size statement: BaseEntity does not set fixedWidth/fixedHeight flags and without those flags width() and height() methods will not use specified values and calculate height/width dynamically using font sizes. Have a look:
BaseEntity.setSizeChars() contains the following lines:

            if (gfr != null && !gfr.isInsideSetup())
            {
               config.fixedHeight = true;
            }

   public static class TbxStaticFDef
   extends WidgetList
   {
      ..
      public void setup(CommonFrame frame)
      {
         ..
         tbbx.setWidthChars(15);
         tbbx.setHeightChars(1.5);
      }
   }

Does gfr.isInsideSetup() check is really needed?

Another bug found for the procedure uast/toggle_box/gui/tglbox_dyn.p. There are toggle-box is created dynamically using CREATE statement:

..
def var tbx as handle.
create toggle-box tbx
   ..
   frame = fFrame:handle.
..

So I can conclude that values assignment happen during enabling widgets in frame (in P2J) that is not right for my test. It is also common bug which is not specific for toggle-box probably.

• when computing the native width, the formula is really 25pixels + the text width; currently , I see that you are using only 11 + 6 + 5 = 22pixels. I've committed to the testcases project the metrics and a program which proves that the formula is correct. So is there a reason why you are using 22 pixels?
• ToggleBoxGuiImpl is missing history entry
• please restore the font-metrics.xml from trunk, the version in 2513b is incorrect

Otherwise, please create a Redmine task named Problems when using the SIZE option for the issue in note 114.

About the issue in note 115: is the drawing performed OK? The test is somehow weird, as it seems 4GL computes the widget's size even if is not attached to a frame... but if this doesn't interfere with drawing/layout, then we can defer this.

Constantin Asofiei wrote:

Vadim, review for 2513b rev 10943:

• when computing the native width, the formula is really 25pixels + the text width; currently , I see that you are using only 11 + 6 + 5 = 22pixels. I've committed to the testcases project the metrics and a program which proves that the formula is correct. So is there a reason why you are using 22 pixels?

Constantin, yes, I remember that you wrote about 25 pixels, but the problem is in the following. The several testcases contain MESSAGE call, that outputs current size attributes values of the toggle-box. If I will use 25 pixels, I will get different MESSAGE output for P2J and PROGRESS. The values will be different. They are the same for 22 pixels. What could be a reason?

About metrics. I expected that it would be font-metrics.xml, but I see only text-metrics.xml. How to use text-metrics.xml?

• ToggleBoxGuiImpl is missing history entry
• please restore the font-metrics.xml from trunk, the version in 2513b is incorrect

Otherwise, please create a Redmine task named Problems when using the SIZE option for the issue in note 114.

About the issue in note 115: is the drawing performed OK? The test is somehow weird, as it seems 4GL computes the widget's size even if is not attached to a frame... but if this doesn't interfere with drawing/layout, then we can defer this.

Yes, drawing is OK. When the widget is attached to a frame in PROGRESS? I thought that assigning frame attibute in CREATE statement should attach it to that frame..

Vadim Gindin wrote:

Constantin Asofiei wrote:

Vadim, review for 2513b rev 10943:

• when computing the native width, the formula is really 25pixels + the text width; currently , I see that you are using only 11 + 6 + 5 = 22pixels. I've committed to the testcases project the metrics and a program which proves that the formula is correct. So is there a reason why you are using 22 pixels?

Constantin, yes, I remember that you wrote about 25 pixels, but the problem is in the following. The several testcases contain MESSAGE call, that outputs current size attributes values of the toggle-box. If I will use 25 pixels, I will get different MESSAGE output for P2J and PROGRESS. The values will be different. They are the same for 22 pixels. What could be a reason?

1. convert all your toggle-box 4GL tests you want to use. There will be a ui_strings.txt file generated
2. copy to windev01 all the files from p2j/tools and also the ui_strings.txt file in the same folder.
3. on windev01, run the get-text-metrics.p using this command:
   

   prowin32 -p get-text-metrics.p
   

4. when prompted, leave the max font size and font-list file name the same. For the textfile, enter ui_strings.txt
5. this will generate you a text-metrics.xml file with the legacy metrics. Copy this to your P2J/testcases environment and run the tests again. This way, FontManager will be able to determine the legacy metrics for the toggle-box label(s).

About metrics. I expected that it would be font-metrics.xml, but I see only text-metrics.xml. How to use text-metrics.xml?

The metrics for the fonts are saved in the stats/ folder using some other format, so you don't need a font-metrics.xml for CheckMetricsToggleBox.java program. The text-metrics.xml I've added contains the metrics for the strings with lengths from 1 to 50, using all fonts with sizes from 1 to 50 (captured as described above, except I've built the text file explicitly).

Yes, drawing is OK. When the widget is attached to a frame in PROGRESS? I thought that assigning frame attibute in CREATE statement should attach it to that frame..

Yes, assigning it to the FRAME does attach it. But if you remove the FRAME assignment, the size-related attributes will still report values... 4GL might do some other adjustments under the hood. Try to work around this for your tests (as you mentioned, move the MESSAGE after the ENABLE, so P2J will report values).

..
Yes, assigning it to the FRAME does attach it. But if you remove the FRAME assignment, the size-related attributes will still report values... 4GL might do some other adjustments under the hood. Try to work around this for your tests (as you mentioned, move the MESSAGE after the ENABLE, so P2J will report values).

When I swapped MESSAGE and ENABLE the window become idle and is not refreshed after the frame is displayed. The testcase is uast/toggle_box/gui/tglbox_dyn.p. If I'll return it back the frame is not even get displayed. I still didn't find the reason.

I've debugged the "idle" problem noted before with the test uast/toggle_box/gui/tbx_events.p and found, that TypeAhead.getKeystroke(..) is called several times (different from time to time: 2 or 6 for me). During the last call of this method the wait(0) is called and it leads to P2J idle. Constantin, did you face this error? How that code should work?

1. ENTER doesn't change toggle-box value for PROGRESS, but for P2J it does.
2. When mouse button is pressed the checkbox background get changed until mouse button is being released. The same for SPACE key.

Does RELEASED event (for keyboard keys) supported in P2J?

Vadim Gindin wrote:

I've debugged the "idle" problem noted before with the test uast/toggle_box/gui/tbx_events.p and found, that TypeAhead.getKeystroke(..) is called several times (different from time to time: 2 or 6 for me). During the last call of this method the wait(0) is called and it leads to P2J idle. Constantin, did you face this error? How that code should work?

The root cause is a NPE in gd.drawString(text, xt, yt); called with null text on ToggleBoxGuiImpl.draw:282. This messes up the batch brackets and the AWT event thread ends up dead-locked in EmulatedWindowState.drawOnScreenBitmap as waitForBatch is negative. If you fix the NPE, it should work.

Vadim Gindin wrote:

Next found toggle-box 2 bugs:

1. ENTER doesn't change toggle-box value for PROGRESS, but for P2J it does.

You need to override processKeyEvent (or maybe processKeyEventCommon?) in ToggleBoxGuiImpl and ignore this key.

1. When mouse button is pressed the checkbox background get changed until mouse button is being released.

You can use the mousePressed() and mouseReleased() events to add the mouse behaviour.

The same for SPACE key.
Does RELEASED event (for keyboard keys) supported in P2J?

No, P2J doesn't have a key pressed/released event notification... all key events are treated as "typed" in P2J. Don't work on this now, document it somewhere in the javadoc/code.

Constantin Asofiei wrote:

Vadim Gindin wrote:

I've debugged the "idle" problem noted before with the test uast/toggle_box/gui/tbx_events.p and found, that TypeAhead.getKeystroke(..) is called several times (different from time to time: 2 or 6 for me). During the last call of this method the wait(0) is called and it leads to P2J idle. Constantin, did you face this error? How that code should work?

The root cause is a NPE in gd.drawString(text, xt, yt); called with null text on ToggleBoxGuiImpl.draw:282. This messes up the batch brackets and the AWT event thread ends up dead-locked in EmulatedWindowState.drawOnScreenBitmap as waitForBatch is negative. If you fix the NPE, it should work.

It helped. Thank you! Couple of questions:

1. The first argument of the method gd.drawString(text, xt, yt); must always be not null. Isn't it?
2. My testcase dynamically creates toggle-box using
   

   create toggle-box tbx
     ..
     label = "BlaBlaBla" 
     ..
   

   
   statement, and that NPE means, that draw method was called somewhere between creation and label settings. Is it OK?

P.S. After I fixed it, label is drawn trimmed to "B". I'm trying to found why at this moment.

Vadim Gindin wrote:

In other words:

1. The first argument of the method gd.drawString(text, xt, yt); must always be not null. Isn't it?

Correct. You can check before calling gd.drawString() if you have a text to draw (don't draw if text is null or empty string).

1. My testcase dynamically creates toggle-box using
   [...]
   statement, and that NPE means, that draw method was called somewhere between creation and label settings. Is it OK?

Yes, I think this might be the trigger - the LABEL was not set when draw was performed.

P.S. After I fixed it, label is drawn trimmed to "B". I'm trying to found why at this moment.

Is the width computed correct?

Constantin Asofiei wrote:

..

P.S. After I fixed it, label is drawn trimmed to "B". I'm trying to found why at this moment.

Is the width computed correct?

You're right. It was a "width" problem. Thank you )

Is there a way to verify color table like font table? I'm running some test where fgColor is set to 5, for example, and Progress shows green text, but P2J - black in spite of color index is the same.

I am trying to understand the open issues and the remaining work on this task.

Vadim:

1. Please create a task for the SIZE issue discussed in notes 113 and 114 above. As Constantin noted, make the title "problems when using the SIZE option". Make sure that task is in the UI project and has a parent task set as #2677. Link to this task (2513) as a "related task" and make both Constantin and myself watchers.

2. Please create a task for the attribute assignment deviation found in note 115 (and discussed through notes 116-119). Make the title "dynamic widgets realize too late". Make sure that task is in the UI project and has a parent task set as #2677. Link to this task (2513) as a "related task" and make both Constantin and myself watchers.

3. The tooltip problem is already known. Eugenie has found it and has been asked to create a task for that.

4. Please create a list of all other open issues and remaining work for this task. Include an estimate of the time needed to resolve each item.

Greg Shah wrote:

I am trying to understand the open issues and the remaining work on this task.

Vadim:

1. Please create a task for the SIZE issue discussed in notes 113 and 114 above. As Constantin noted, make the title "problems when using the SIZE option". Make sure that task is in the UI project and has a parent task set as #2677. Link to this task (2513) as a "related task" and make both Constantin and myself watchers.

Already created: the task #2742.

2. Please create a task for the attribute assignment deviation found in note 115 (and discussed through notes 116-119). Make the title "dynamic widgets realize too late". Make sure that task is in the UI project and has a parent task set as #2677. Link to this task (2513) as a "related task" and make both Constantin and myself watchers.

Created: the task #2744.

3. The tooltip problem is already known. Eugenie has found it and has been asked to create a task for that.

4. Please create a list of all other open issues and remaining work for this task. Include an estimate of the time needed to resolve each item.

1. Some layout problem I wrote in the note 130.
2. Events problem: need to suppress VALUE-CHANGED event if low level trigger (LEFT-MOUSE-CLICK for example) is defined. I've asked for advice how to do it in the note 128.

Have also look at the note 129. Color table verification. I'm not sure if it is a bug: colors are different in P2J and Progress with the same index.

Vadim Gindin wrote:

1. Tooltip does not hiding correctly.
2. I have 2 triggers: VALUE-CHANGED and LEFT-MOUSE-CLICK. If LEFT-MOUSE-CLICK is defined VALUE-CHANGED trigger is not called in PROGRESS. How to correctly track that LEFT-MOUSE-CLICK trigger or other similar low level trigger is defined? Is it works already somewhere?

This is not currently supported by P2J, in a generic way. I think you need to change ToggleBox.check() and not post the VALUE-CHANGED event if the TC.currentEventList has a MOUSE-LEFT-CLICK trigger for this widget.

Vadim Gindin wrote:

Have also look at the note 129. Color table verification. I'm not sure if it is a bug: colors are different in P2J and Progress with the same index.

I don't think this is an issue, is most likely a configuration difference between your directory.xml and progress.ini on windev01. If you have a color-table node in your directory, you can rename it to something else (if you comment it, it will get lost) and this will fallback to the implicit color-table. On windev01, again make sure the color-table in your progress.ini was not changed (or better do not use an explicit progress.ini, start prowin32 directly).

I've found, that MOUSE-SELECT-DOUBLE-CLICK event is processed by P2J differently than in a PROGRESS. Let assume, we have 2 triggers for toggle-box: VALUE-CHANGED and MOUSE-SELECT-DBLCLICK. PROGRESS will call triggers double-click event in the following order:

mouse-select-dblclick
value-changed

value-changed
value-changed
mouse-select-dblclick

Here is the testing procedure:

def var tbx as handle.
def button exit_btn label "exit exit exit".

def frame f skip(1) exit_btn no-labels.

create toggle-box tbx
  assign
  name = "tbx" 
  frame = frame f:handle
  visible = true
  sensitive = true
  label = "BlaBla".

enable all with frame f.

on value-changed of tbx
  message "value-changed".

on mouse-select-dblclick of tbx
  message "mouse-select-dblclick".

wait-for choose of exit_btn.

Is it a known problem with double-click event processing?

I think P2J might raise both mouse-clicked and mouse-dblclicked events. Please check the click-count for a mouseClicked event - if is 2, it should not have been raised.

Otherwise, this might be a Swing issue - it might raise a mouse-clicked event and only after that a mouse-dblclicked...

I've found that LASTKEY is not modified by MOUSE-SELECT-CLICK events (may be other mouse events too), but PROGRESS does modification. More over PROGRESS set LASTKEY=MOUSE-SELECT-UP for both MOUSE-SELECT-CLICK or MOUSE-SELECT-DBLCLICK event. What is the best place to set LASTKEY? I would propose MouseHandler.mouseClicked(MouseEvent). What do you think?

Vadim Gindin wrote:

I've found that LASTKEY is not modified by MOUSE-SELECT-CLICK events (may be other mouse events too), but PROGRESS does modification. More over PROGRESS set LASTKEY=MOUSE-SELECT-UP for both MOUSE-SELECT-CLICK or MOUSE-SELECT-DBLCLICK event. What is the best place to set LASTKEY? I would propose MouseHandler.mouseClicked(MouseEvent). What do you think?

No, this is not the correct place. I think it should be TC.waitForEvent(int, boolean, boolean, boolean), where the event is picked up and processed.

I've committed my last changes and rebased the branch. Current revision is 10955. Please review.

Constantin Asofiei wrote:

Vadim Gindin wrote:

Have also look at the note 129. Color table verification. I'm not sure if it is a bug: colors are different in P2J and Progress with the same index.

I don't think this is an issue, is most likely a configuration difference between your directory.xml and progress.ini on windev01. If you have a color-table node in your directory, you can rename it to something else (if you comment it, it will get lost) and this will fallback to the implicit color-table. On windev01, again make sure the color-table in your progress.ini was not changed (or better do not use an explicit progress.ini, start prowin32 directly).

My directory.xml does not contain color-table and I'm running PROGRESS without specifying progress.ini. Colors are different: PROGRESS shows green rectangle around the toggle-box (when it is focused) and P2J shows black rectangle (looks like it uses regular color). Are you sure it is okey? The testcase /uast/toggle-box/gui/tbx_static2.p

Code Review Task Branch 2513b Revision 10955

This seems quite a good improvement.

1. Please add a history entry to SwingKeyboardReader.

2. In ToggleBoxGuiImpl, is the explicit import of com.goldencode.p2j.ui.client.event.Key needed due to a conflict?

3. In ToggleBoxGuiImpl.initialize(), the call to gd.registerTooltipWorker() should be removed. Tooltip processing is now implemented generically in the parent hierarchy.

4. Are you sure you should be replacing the font-metrics.xml? I suspect you should not change that file.

Vadim, I don't see any other issue in 2513b rev 10955 except what Greg noted.

Constantin Asofiei wrote:

Vadim, I don't see any other issue in 2513b rev 10955 except what Greg noted.

Yes, that is the last one.

As Greg mentioned, it might be a XOR formula; Stanislav found this related while working on BROWSE widget: #2564-58

Please do some checks if the selection follows the inverse = color XOR 192 formula (Stanislav also found that you need to print screen and check the color from within windev01, otherwise the colors might not be correct). If it does follow the formula, then support is already added in #2564 (XORComposite in Java2D).

Constantin Asofiei wrote:

Vadim, I don't see any other issue in 2513b rev 10955 except what Greg noted.

Constantin, you may want to look at lastkey set for mouse events in TC.waitFor(..).

Vadim Gindin wrote:

I need some help with XOR experiments. I've added the following code to the method that draws rectangle around the label ToggleBoxGuiImpl.drawHighlight():
[...]
before rectangle drawing. Here is the results: When toggle-box get the focus some colors are changed to the right color (green). My code is probably not correct, but It looks like it computes xor color correctly. Could you help me with it?

Your code is using Swing APIs outside of the Swing driver, so this is not OK.

Also, please take the XOR-related changes done by Stanislav in #2564 - these should help you. I don't think is needed to implement a separate XOR mechanism for your case.

There are 2 branches: 2564a and 2564b. Which one? How to properly take Stanislav's changes: merge branches by hand or somehow rebase it like rebasing with trunk?

Stanislav, can you help Vadim isolate the XOR-drawing changes in 2564b, so he can use/test them for the toggle-box?

Let's defer this XOR color work until after 2564b is merged to trunk. I don't want to mess with pulling just the XOR changes out.

Please get the branch ready for final review and testing. Are there any other changes you need to apply to address the previous notes? I want you to get this into testing today.

Greg Shah wrote:

Let's defer this XOR color work until after 2564b is merged to trunk. I don't want to mess with pulling just the XOR changes out.

Please get the branch ready for final review and testing. Are there any other changes you need to apply to address the previous notes? I want you to get this into testing today.

The branch is ready. There are no other changes.

Code Review Task Branch 2513b Revision 10956

I'm good with the changes. Please start regression testing. You don't have to run conversion regression testing (but you will have to make sure your converted MAJIC code is fresh). Just run the runtime regression testing.

Please rebase ASAP. I'll do a final review and then you can start testing.

You'd asked me to wait for 2564b to be merged to the trunk, but Stanislav has merged 2564a. Please confirm rebasing.

My mistake, it is 2564a that we were waiting on.

Please go ahead with the rebase now.

I've rebased the branch just now. Please review.

Code Review Task Branch 2513b Revision 10957

It looks good. Please start testing immediately.

Vadim Gindin wrote:

Here is testing result of failed test tc_codes_employees.txt attached. It contains the test screen and expected screen. The difference is in last 2 of strings in the table. How that can be related to my toggle-box changes?

How does it look if you test it manually? Does the screen still fail?

Yes, it fails.

This could happen due to timing and the lack of proper dependency encoding in our tests for this case. It looks to me like there are just some extra records in a table somewhere that were not expected by the test.

Try this:

1. Restore your database instance on devsrv01.
2. Recycle your GSO server instance.
3. Manually test again.
4. Report your results here.

Greg Shah wrote:

This could happen due to timing and the lack of proper dependency encoding in our tests for this case. It looks to me like there are just some extra records in a table somewhere that were not expected by the test.

Try this:

1. Restore your database instance on devsrv01.

I didn't do that before. How to do that or where it is documented?

2. Recycle your GSO server instance.

What do you mean by word "recycle"? May be "rerun"?

3. Manually test again.
4. Report your results here.

It is documented in the timco.html.

The first two items are both done with a single command: run_regression.sh server-startup

It will shut down the servers, restore the DB and then startup the servers.

What do you mean by word "recycle"? May be "rerun"?

Stop and then restart.

I did it. tc_codes_employees_016 has passed. login_to_main_menu and logout_from_main_menu have failed.

login_to_main_menu and logout_from_main_menu have failed.

What do you mean?

Weren't you testing manually?

I used run_single.sh... I didn't understand you correctly. Now would you insist for me to run it by hand (i.e. server.sh -i10, client.sh -i10 and manually go through test steps)?

Now would you insist for me to run it by hand

No, but I do want to understand why login/logout failed.

client.sh -i10

If run_single.sh works for a specific test, then use that. Sometimes, a test can't be run that way and then "manually go through test steps" would be the thing to do.

In your case, the test passes. That is good. We just need to make sure the login/logout problem is not really a problem. Can you please provide details on why those failed?

How did tc_codes_employees_016 pass if login failed?

I have quite a bit to do other than this right now. Can you please tell me what you have found. I assume you have tried to analyze the results yourself and must have some understanding that you can share here.

Greg Shah wrote:

I have quite a bit to do other than this right now. Can you please tell me what you have found. I assume you have tried to analyze the results yourself and must have some understanding that you can share here.

I find nothing at this moment. Empty logs. I've tried to look at majic sources and timco docs. I've only thought about obvious thing: that login/logout bogus errors happen only after the servers restart and can be related with that somehow.

Please just test this by hand (NOT with run_single.sh).

Wait. I just looked at the results zip you posted. The failures occur on thread Driver 0. The actual tests login, execute tc_codes_employees_016 and then logout on thread Driver 1. There are 2 threads defined for majic_single.xml, although only one is needed. I'm not sure why the Driver 0 thread failed, but it really doesn't matter. We can consider this test passed and there is no issue with login/logout.

Perhaps you should have just run this with a single thread.

Please merge 2513b to trunk.

OK, I've just run at by hand and all works, login/logout and tc_codes_employees_016.

The branch is merged to trunk as rev 10947