FWD » Core Development » User Interface

The following call (found in testcases) causes an error:

dtWidget:CalendarValue = NOW.

Here dtWidget is a Calendar widget.

The call is converted as

         dtWidget.unwrapCalendar().setCalendarValue(new character(datetimetz.now()));

The result of execution of new character(datetimetz.now()) includes the time zone spec (see also #5734), which cannot be parsed into LocalDataTime.

I think, setters need to be added for all kinds of date/datetime objects instead of printing them to string first and parsing the result back. Conversion procedure shall be adjusted accordingly.

I do not think the character wrapper is correct. Without it, that line would be generated as:

dtWidget.unwrapCalendar().setCalendarValue(datetimetz.now());

which should be correct syntactically, because datetimetz (returned by now()) is a datetime and we already have

@LegacyAttribute(name = "CalendarValue", setter = true)
public void setCalendarValue(datetime value);

declared in the Calendar interface.

Ovidiu Maxiniuc wrote:

I do not think the character wrapper is correct. Without it, that line would be generated as:
[...]

which should be correct syntactically, because datetimetz (returned by now()) is a datetime and we already have
[...]

declared in the Calendar interface.

Yes, this must be done. Also, at least, #5734 must be fixed, for this call to complete with no errors.

Hi guys,

I want to fix this issue, but I need some hints for where to find the code that converts statements like this.

Thanx.

I think this is OCX specific. You can start by looking at wrap_parameter / com-argument-wrap annotations. If this is not the case, chp_wrapper annotation could be cause.

When facing a conversion issue I think it is always recommended to start with a specific test case. Look at the conversion artifacts (I mean the associate .ast/.jast files). Try to locate the problem AST and its unique id. See which rules create / modify / annotate it. A node may evolve during different phases of conversion and you may need to back-track to flaw location.

Hope this helps!

Thank you, Ovidiu.

Ovidiu Maxiniuc wrote:

I think this is OCX specific. You can start by looking at wrap_parameter / com-argument-wrap annotations. If this is not the case, chp_wrapper annotation could be cause.

Calendar is converted as an ordinary widget here, so I doubt, there is anything OCX-specific involved here.

When facing a conversion issue I think it is always recommended to start with a specific test case.

I have one already.

Look at the conversion artifacts (I mean the associate .ast/.jast files). Try to locate the problem AST and its unique id. See which rules create / modify / annotate it. A node may evolve during different phases of conversion and you may need to back-track to flaw location.

The problem is in the AST already:

        <ast col="9" id="249108103273" line="15" text=":" type="COLON">
          <ast col="1" id="249108103274" line="15" text="dtWidget" type="VAR_HANDLE">
            <annotation datatype="java.lang.Long" key="oldtype" value="2935"/>
            <annotation datatype="java.lang.Long" key="refid" value="249108103171"/>
            <annotation datatype="java.lang.Long" key="support_level" value="16400"/>
            <annotation datatype="java.lang.Long" key="peerid" value="253403070568"/>
          </ast>
          <ast col="10" id="249108103275" line="15" text="CalendarValue" type="ATTR_CHAR">
                                                                         ^^^^^^^^^^^^^^^^^^
            <annotation datatype="java.lang.Long" key="oldtype" value="2834"/>
          </ast>
        </ast>

The type of the assignment left side value is ATTR_CHAR here. But the Calendar widget provides 3 setters for the CalendarValue with 3 different types of the argument. A wonder if this situation is supported. If not, we can replace these 3 setters by one with the Object or BaseDatatype parameter type, which will be dispatch the operation based in the concrete parameter type.

I understand. The attribute type is given in progress.g by the declaration:

attrsAndMethods.put( KW_CALVALUE, ATTR_CHAR    ); // FWD CALENDAR:CalendarValue extension, not real 4GL

This means the getter. The setter accepts a wider range of parameters. In this case, we need to analyse the type of the parameter before injecting the cast. If ExpressionConversionWorker / ecw.expressionType() applied to KW_CALVALUE's first child returns one of the 'native' types, the case is unnecessary and may be incorrect, as in this case.