FWD » Core Development » User Interface

Starting in trunk 10948 or 1811s 10994, run message-update6.p.

Enter "Y" to the first prompt. At the second prompt, there should be a numeric format "99" but it does not edit properly. Typing "8" should result in "08" but instead it results in "80".

Task branch 1811s for review updated to revision 11020.

This message update fix. Now the digit value displays properly on pressing 8.

It looks good. Let me know when you have the unknown value fix.

Greg Shah wrote:

It looks good. Let me know when you have the unknown value fix.

I'm thinking about this issue. For now I can not tell exactly about time frame. Because it is possible the conversion level rule changes can be required to implement this(to generate setUnknown() method for integer variable). Need to perform some testing in 4GL to see if we can make only runtime change(for example if any integer without init value can be considered as unknown).

Because it is possible the conversion level rule changes can be required to implement this(to generate setUnknown() method for integer variable).

The original testcase explicitly initializes the variable to unknown value:

def var num as int init ?.

We support this already. The java code:

integer num = new integer();

num will be set to unknown value in P2J too. This is not the issue.

Need to perform some testing in 4GL to see if we can make only runtime change(for example if any integer without init value can be considered as unknown).

By default, when an init value in the 4GL is omitted for an integer variable, the initial value is 0. We support this just fine. In our case, we actually DO have an initial value specified, it is the ? literal. As noted above, this is not the problem.

The issue is in the UI. Either we are not storing the unknown value properly in the screen buffer. Or if it is properly in the screen buffer, we are not honoring it in the DisplayFormat and/or the FillInGuiImpl.

Either we are not storing the unknown value properly in the screen buffer. Or if it is properly in the screen buffer, we are not honoring it in the DisplayFormat and/or the FillInGuiImpl.

Hmmm, actually this is not right. We don't use screen buffers for MESSAGE UPDATE. The problem is in LogicalTerminal.message(), ThinClient.message() or in Window.tinyInput(). Somewhere in there, we don't handle unknown value properly.

You are right, the integer variable is properly initialized as unknown and passed to the client side without change. The problem begins when Window class reconstructs the FillIn widget to display within the message(Window.tinyInput()). Looking for solution. Expect to have it later today.

In 4GL for GUI and ChUI the processing of the initial unknown value is the same:
- All data types are able to use "?" as iniitial value except date
- The date type variable does not display "?" initially.

In P2J the problematic place is in Window.tinyInput():

...
      if (!var.isUnknown())
         sb.putWidgetValue(id1, var.duplicate());
...

Preparing the solution and additional testcases to verify the fix.

The addition, date exception means all data related variables: date, datetime and datetime-tz. All of them do not display ? initially in both ChUI and GUI.

The standalone testcase has been added to repo to check different data types:message-update7.p revision 1389. The testing shown the correct behavior for ChUI and GUI. Going to commit into 2677a when initial repo pulling will be done.

Task branch 2677a for review updated to revision 10952.

The fix for initial unknown value for MESSAGE UPDATE statement. Checked to compare with ChUI and GUI modes.

The cursor position in P2J is located before the digit typed, while in 4GL it is located after.

Looks like a kind of cursor location handling error in FillInGuiImpl. Should this bug be fixed in this task or it is already under fixing in some other task? Or need to create separate task for it?

Constantin: do you expect to fix this in #2727?

Greg Shah wrote:

The cursor position in P2J is located before the digit typed, while in 4GL it is located after.

Looks like a kind of cursor location handling error in FillInGuiImpl. Should this bug be fixed in this task or it is already under fixing in some other task? Or need to create separate task for it?

Constantin: do you expect to fix this in #2727?

This is something specific for numeric formats; yes, I can work on it part of #2727.