FWD » Core Development » User Interface

Start by writing testcases to demonstrate the toggle-box behavior and all its options.

Do we need to cover only ChUI area? Or including Graphical Interface for Windows too?

For now, we don't have GUI support yet in the rest of the client. So you can only implement ChUI right now. Later on, we will add GUI support.

Please add tests for the following cases:

1. Check if ATTR-SPACE or other options can have an impact on the label positioning. All the labels in your examples are missing a space between the brackets and the label ([ ]label instead of [ ] label). This doesn't look right.

2. From the 4GL docs:

You can specify TOGGLE-BOX for any LOGICAL value, or any calculated value whose expression evaluates to a LOGICAL value.

How can we use "any calculated value whose expression evaluates to a LOGICAL value"? Try to create an example.

3. Make sure you ASSIGN the results of the edits back to the original lvalues and then use them in the following code. This proves that your testcases works (and will be a better test of P2J).

Also: please check all these into testcases/uast/toggle_box/.

ATTR-SPACE can be put into the frame phrase:

DISPLAY my-toggle-var WITH FRAME my-frame ATTR-SPACE.

Testcases have been committed in bzr as 1146.

CHUI does not make the extra space. I think in theory it is possible to simulate [ ] label layout in CHUI by defining TOGGLE-BOX without any label(or empty label) and drawing the label text by other statement(PUT SCREEN for example). Or we can do even more simple - by defining the label for TOGGLE-BOX with embedded extra space in label text front: " label text".

Don't worry about the space between the brackets and the label in ChUI mode. If the 4GL doesn't have an option that does it, then we won't either. The testcase screen shots just looked awkward, so I wondered if we were missing something. I guess the Progress 4GL designers just weren't very careful in their approach.

2. On the other hand in my understanding the words "...calculated value whose expression evaluates..." in 4GL doc here means to have boolean variable anyway that accept the result of the expression evaluating:

...
boolRes = intVar2 >= intVar1.
display boolRes view-as toggle-box ...
...

We don't have to do anything to support this.

When you convert your testcases, what is the result? We had already put in some support as far as I know, so what is left to do on the conversion part?

1. To define isChecked() to the CommonWidget interface

Yes, you certainly need to add stubbed support for the CHECKED attribute.

2. To find out if the DynamicWidgetFactory.createToggleBox(toggle1, "VALUE-CHANGED", TriggerBlock0.class, ToggleBox4.this); is the correct creation procedure and why it is not compiling if it is correct.

No this is not correct. The problem is due to the fact that we do not support the TRIGGERS phrase. As far as I know, we don't need to support that at this time. Please just use a standard ON statement to setup the trigger separately from the CREATE widget statement.

Code Review 0609a

Please test how unknown value works for the CHECKED attribute and implement it in ToggleBoxWidget.setChecked(logical checked). Otherwise the changes look good. Please get this done quickly so we can move on.

Please test how unknown value works for the CHECKED attribute and implement it in ToggleBoxWidget.setChecked(logical checked). Otherwise the changes look good. Please get this done quickly so we can move on.

The runtime error has been generating when trying to set CHECKED attribute to unknown:

...
**Unable to assign UNKNOWN value to attribute CHECKED on TOGGLE-BOX @TOGGLE-BOX variable name@. (4083)
...

Code Review 0609b

1. The GenericWidget.isChecked()/setChecked() methods should simply execute: throw new RuntimeException("CHECKED attribute is undefined");.

2. Please do implement the error processing for unknown value. The Progress name is kept during conversion. You should be able to read the widget name from the GenericFrame.getOriginalName() method.

3. In regard to your question:

In getter method we need to choose which one we leave, either returning boolean or logical value because we can not have both simultaneously.

All attribute getters must return wrappers (e.g. logical) instead of Java primitives. Otherwise, how would we handle things like when an attribute is set to unknown value?

Code Review 0610a

It looks good.

Code Review 0611a

This is a very good start.

1. Please rename ToggleBoxImpl.drawChekBox() to ToggleBoxImpl.drawCheckBox().

2. The RadioButton can only be used as a set of related buttons in a ButtonGroup. It has quite a bit of behavior that is unique to its "mutually exclusive" button behavior. I suspect it is not a good fit as a model for ToggleBox, since ToggleBox does not have the grouping features. On the other hand, I do agree that Button is probably very close. If your approach (to base ToggleBox on Button) does work out, please create a common base class for Button/ToggleBox and move all the common code into that class.

1. Please rename ToggleBoxImpl.drawChekBox() to ToggleBoxImpl.drawCheckBox().

OK. Sorry this was just syntax error.

2. The RadioButton can only be used as a set of related buttons in a ButtonGroup. It has quite a bit of behavior that is unique to its "mutually exclusive" button behavior. I suspect it is not a good fit as a model for ToggleBox, since ToggleBox does not have the grouping features. On the other hand, I do agree that Button is probably very close. If your approach (to base ToggleBox on Button) does work out, please create a common base class for Button/ToggleBox and move all the common code into that class.

OK. The main differences from Button(in addition to CHECKED attribute) on my guess are: the ToggleBox has internal value to be set/get and does not have AutoGo feature in key handling. And this means we need the DataContainer interface to be implemented for ToggleBox. And key processing is also different in ToggleBox comparing to Button.

Code Review 0611b

The changes look fine.

Code Review 0613a

The changes look good. The only thing to change is to save off the screen-buffer changes into the config instance. I'm not sure it will make a difference, but it will make the state of that more consistent, which may save an error later.

Code Review 0613b

The changes look fine.

the message will display for all such widgets, not for the first encountered as I could expect. I think the key word here is "realise" in the message which may mean trying to place it to the frame(may be view() call in term of P2J).

Yes, "realize" means the first time that a given frame is made visible. There are some things that only happen at that time. For example, one can only set the PARENT attribute of a FRAME before it is realized.

If you can implement the realize error processing at the server, it is best. Please note that it probably does not raise an ERROR condition, otherwise you would not see multiple messages.

The other question is about dynamically created widget support(toggle_box4.p test).
1. Do we have this for other widgets?

Yes, we at least support conversion for dynamic widgets. I'm not sure how complete our runtime support is, but I suspect it is pretty close because our conversion approach uses many of the same methods that we already use for static widgets/frames.

2. If yes, what level of support for toggle-box we need here?

Please provide the same level of support as we have for other widgets.

I'm asking because for example the order of option in create toggle-box ... assign ... is very important. If we put FRAME = FRAME f1:HANDLE after option that requires frame value to be set - the NullPointerException will be raised(there is no valid frame defined at this time in this case).

What does the 4GL do here? I believe that this can't be done in the 4GL either. It probably raises an error. We should do the same thing, but we may wait on that since it could require lots of code to be implemented across all places that are sensitive. Please investigate the behavior and post it here. Then we will probably create a new task and defer the work.

The problematic area is marked in red. I think this is something like phantom cursor. It is blinking and disappears when moving focus to another widget. There is no such effect in 4GL.

Yes, please fix it.

I have added a note to #1791 to describe the problem and to reference note 30 in this task. You don't need to do anything further on this ordering problem right now.

The problematic area is marked in red. I think this is something like phantom cursor. It is blinking and disappears when moving focus to another widget. There is no such effect in 4GL.

Yes, please fix it.

Debugging shows the root cause. This is the ThinClient.waitForWorker()(as the part of the update() sequence) the line 9344:

...
         if (status)
         {
            startInputStatus(true);
            statusSet = true;
         }
...

I think the solution can be do not force the cursor ON if the widget to be focused is not expecting this. The ToggleBox is the case. Some widgets require the cursor(like FillIn) but some does not(like ToggleBox or Button I guess).

The fix for now can be the following modification of the ThinClient.waitForWorker() code:

...
         if (status)
         {
            Widget widOnFocus = UiUtils.getCurrentFocus();

            startInputStatus((widOnFocus == null) || !(widOnFocus instanceof ToggleBox));
            statusSet = true;
         }
...

...
         if (status)
         {
            Widget widOnFocus = UiUtils.getCurrentFocus();

            startInputStatus((widOnFocus == null) || widOnFocus.forceCursorOnFocus());
            statusSet = true;
         }
...

What do you think about these approaches?

Another point - the current ToggleBox handles correctly the widget messages: VALUE-CHANGED, ENTRY and LEAVE. This is all we need from messages perspective, right?

Code Review 0617a

1. In the javadoc for these changes, "cusror" should be "cursor".

2. The javadoc for ToggleBoxImpl.forceCursorOnFocus() should explain that the return value is always false.

What do you think about these approaches?

I really like the approach. The code is good.

the current ToggleBox handles correctly the widget messages: VALUE-CHANGED, ENTRY and LEAVE. This is all we need from messages perspective, right?

I think so.

Is there anything left to do in this task?

2. The javadoc for ToggleBoxImpl.forceCursorOnFocus() should explain that the return value is always false.

OK.

Is there anything left to do in this task?

Two things:
1. Verify the dynamically creation widget code works on the same level as for other widgets.
2. Implement the error messages and application interrupt when trying to realize the toggle-box with width less than 3(mandatory minimum size for toggle-box).

Also may be as one more thing to do is to refactor the Button and ToggleBox implementation to merge possible common code in separate class. But may be we do not need this because the differences we have can be more than commons.

Also may be as one mo thing to do is to refactor the Button and ToggleBox implementation to merge possible common code in separate class

Please do this refactoring now.

Also may be as one more thing to do is to refactor the Button and ToggleBox implementation to merge possible common code in separate class

Please do this refactoring now.

OK.

And BTW for dynamic widget creation. I guess the level support is the same. I have compared Button and ToggleBox created by CREATE WIDGET .... The result is the same - converted and complied but at runtime we have exception(same exception for both Button and ToggleBox):

...
java.lang.IllegalStateException: Missing type attribute for method mapping entry [method-mapping: null]
    at com.goldencode.p2j.util.SourceNameMapper.buildMethod(SourceNameMapper.java:1164)
    at com.goldencode.p2j.util.SourceNameMapper.buildExternalProgram(SourceNameMapper.java:1070)
    at com.goldencode.p2j.util.SourceNameMapper.initMappingData(SourceNameMapper.java:996)
    at com.goldencode.p2j.util.SourceNameMapper.convertJavaProg(SourceNameMapper.java:192)
    at com.goldencode.p2j.util.SourceNameMapper.convertJavaProgSafe(SourceNameMapper.java:208)
    at com.goldencode.p2j.util.BlockManager.checkJavaCall(BlockManager.java:6978)
    at com.goldencode.p2j.util.BlockManager.topLevelBlock(BlockManager.java:6829)
    at com.goldencode.p2j.util.BlockManager.externalProcedure(BlockManager.java:218)
    at com.goldencode.p2j.util.BlockManager.externalProcedure(BlockManager.java:200)
    at com.goldencode.testcases.toggle_box.ToggleBox4.execute(ToggleBox4.java:18)
    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:1237)
    at com.goldencode.p2j.main.StandardServer$MainInvoker.execute(StandardServer.java:1679)
    at com.goldencode.p2j.main.StandardServer.invoke(StandardServer.java:1179)
    at com.goldencode.p2j.main.StandardServer.standardEntry(StandardServer.java:363)
    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:693)
    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)
[06/18/2014 20:00:02 MSK] (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:1237)
        at com.goldencode.p2j.main.StandardServer$MainInvoker.execute(StandardServer.java:1679)
        at com.goldencode.p2j.main.StandardServer.invoke(StandardServer.java:1179)
        at com.goldencode.p2j.main.StandardServer.standardEntry(StandardServer.java:363)
        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:693)
        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.RuntimeException: Unable to load name mapping data.
        at com.goldencode.p2j.util.SourceNameMapper.initMappingData(SourceNameMapper.java:1005)
        at com.goldencode.p2j.util.SourceNameMapper.convertJavaProg(SourceNameMapper.java:192)
        at com.goldencode.p2j.util.SourceNameMapper.convertJavaProgSafe(SourceNameMapper.java:208)
        at com.goldencode.p2j.util.BlockManager.checkJavaCall(BlockManager.java:6978)
        at com.goldencode.p2j.util.BlockManager.topLevelBlock(BlockManager.java:6829)
        at com.goldencode.p2j.util.BlockManager.externalProcedure(BlockManager.java:218)
        at com.goldencode.p2j.util.BlockManager.externalProcedure(BlockManager.java:200)
        at com.goldencode.testcases.toggle_box.ToggleBox4.execute(ToggleBox4.java:18)
        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:1237)
        at com.goldencode.p2j.main.StandardServer$MainInvoker.execute(StandardServer.java:1679)
        at com.goldencode.p2j.main.StandardServer.invoke(StandardServer.java:1179)
        at com.goldencode.p2j.main.StandardServer.standardEntry(StandardServer.java:363)
        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:693)
        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)
...

So I think this is not ToggleBox specific and we can postpone this subtask if you do not mind. Let me know if any notes or objections.

OK, no objections.

Code Review 0618a

The changes look good. The only thing needed is to properly sort the methods in AbstractButton and ToggleBox (public then protected then private...).

Code Review 0619a

1. We can't reuse valid() because this is there for other reasons (to provide support for the HANDLE:IS-VALID built-in function). Please use a new method named preRealizeCheck().

2. Does the 4GL really exit out from this error in an unstoppable way (UnstoppableExitException)? Or does it raise a real STOP or QUIT when this occurs?

The remaining issue is in P2J we have additional message "Press space bar to continue." while in 4GL the only message before stop is "Procedure complete. Press space bar to continue.".

This sounds like a QUIT (QuitConditionException). Check this before you make any other changes.

This sounds like a QUIT (QuitConditionException). Check this before you make any other changes.

Yes, looks like you are right. This is the usual exit for CHUI client session in 4GL for application finish. I opened the testcase in 4GL CHUI client session and after error messages and "Procedure complete. Press space bar to continue." the testcase finishes as if it goes from start to finish without errors.

So I guess this is the QuitConditionException and generating this exception the P2J works the same as 4GL.

Yes, looks like you are right. This is the usual exit for CHUI client session in 4GL for application finish.
...
QuitConditionException to quit the client session for realize errors

Please show the testcase you are using for checking the error processing. Does the 4GL really cause a QUIT for this case? That is very unusual.

If you enclose the code in a block like this:

DEF VAR err-flag AS LOGICAL INIT true.
DO ON ERROR UNDO, LEAVE:
  /* code that may generate an error */
  err-flag = false.
END.

if err-flag then
   MESSAGE "There was an ERROR.".

Then you can tell if the code generates an error or not. You can also try ON END-KEY, ON STOP and ON QUIT instead of ON ERROR. If there is an ERROR, you can also use NO-ERROR and then check the ERROR-STATUS handle to see if it is recorded properly.

Please check all of this so we can be sure to match the proper behavior.

Also: check in your final testcases.

Code Review 0620a

The code looks good, especially the refactoring of common code into buildWidgetSpectificMessage(). Once you finish your testing as described in note 47, we will know if this is the final code or not.

Code Review 0622a

I'm fine with the changes. Please get it regression tested (both conversion and runtime).

The conversion part has been finished. The converted code is binary equal. Continue with runtime testing.

Please check in your testcases to testcases/uast/toggle_box/.

Code Review 0624a

The changes look good.

Please check in your testcases to testcases/uast/toggle_box/.

Done. The revision is 1157.

The main regression part completed without regression. Continue with CTRL-C part.

The CTRL-C part has been completed without regressions. Hopefully 2-way and 3-way in a single session. The results have been uploaded to GCD share directory. I'm planning to commit the update in bzr withing 15 min. if there are no objections and distribute.

Go ahead with the check-in and distribution.

The update 0624a has been committed in bzr as 10552.