FWD » Core Development » Conversion Tools

Moved from #5034-1198 (by Vladimir):

Gentlemen,

I'm stuck converting code related to TREEVIEW/TREELIST.

The problem is with 4gl functions having COMPONENT-HANDLE type as function parameters.

I tried the two following functions, which differ only in how they declare their argument. The theFunction declares it as HANDLE, while the theFunction1 declares the argument as COMPONENT-HANDLE.

FUNCTION theFunction RETURNS LOGICAL (INPUT theNode AS HANDLE):
  ASSIGN theNode = theNode:Parent.
  RETURN TRUE.
END FUNCTION.

FUNCTION theFunction1 RETURNS LOGICAL (INPUT theNode AS COMPONENT-HANDLE):  
  ASSIGN theNode = theNode:Parent.
  RETURN TRUE.
END FUNCTION.

The .ext-hints file provides the following hint for the theNode:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<extension>
   <ocx com-handle="theNode" 
        target-widget="com.goldencode.p2j.ui.TreeNodeFace" 
        target-handle="theNode"/>
</extension>

Both conversions result in non-compilable Java code:

   @LegacySignature(type = Type.FUNCTION, name = "theFunction", returns = "LOGICAL", parameters = 
   {
      @LegacyParameter(name = "theNode", type = "HANDLE", mode = "INPUT")
   })
   public logical theFunction(final handle _theNode)
   {
      handle theNode = TypeFactory.initInput(_theNode);

      return function(this, "theFunction", logical.class, new Block((Body) () -> 
      {
         theNode.assign(theNode.unwrapWidget().getParentHandle());
         returnNormal(true);
      }));
   }

   @LegacySignature(type = Type.FUNCTION, name = "theFunction1", returns = "LOGICAL", parameters = 
   {
      @LegacyParameter(name = "theNode", type = "COMHANDLE", mode = "INPUT")
   })
   public logical theFunction1(final comhandle _theNode)
   {
      comhandle theNode = TypeFactory.initInput(_theNode);

      return function(this, "theFunction1", logical.class, new Block((Body) () -> 
      {
         theNode.assign(theNode.unwrapTreeNodeFace().getParentNode());
         returnNormal(true);
      }));
   }

For the first function, the conversion as theNode.unwrapWidget().getParentHandle() is outright wrong, since the object is not a widget.
For the second function, the conversion is correct, but the Kava argument type is comhandle instead of expected handle.

I have no problem using COMPONENT-HANDLE as the 4gl procedure argument type.

The problem with the first function is that there is already a 4GL PARENT attribute that can be accessed on a HANDLE. This "built-in" attribute takes precedence over our OCX conversion. It is not really a bug at all. This is how it should work.

The second function use of comhandle probably needs the caller to "wrap" any handle as a comhandle.

I have no problem using COMPONENT-HANDLE as the 4gl procedure argument type.

Do you mean that if you use a procedure instead of a function, then the converted code is OK? If that is not what you mean, then I need a clarification.

Greg Shah wrote:

The problem with the first function is that there is already a 4GL PARENT attribute that can be accessed on a HANDLE. This "built-in" attribute takes precedence over our OCX conversion. It is not really a bug at all. This is how it should work.

Agreed, if I change the Parent to LastSibling, the result does not convert at all. The problem I cannot find a working solution to convert code which works OK in 4gl. It is either a bug, or, my .ext-hints may be incorrect or incomplete.

The second function use of comhandle probably needs the caller to "wrap" any handle as a comhandle.

The problem is the output of the second function is not correct Java: the function argument of comhandle type cannot be unwrapped to a TreeNodeFace.

I have no problem using COMPONENT-HANDLE as the 4gl procedure argument type.

Do you mean that if you use a procedure instead of a function, then the converted code is OK? If that is not what you mean, then I need a clarification.

Yes. The following converts to a correct Java:

PROCEDURE theProcedure :
  DEFINE INPUT PARAMETER theNode AS COMPONENT-HANDLE NO-UNDO.
  ASSIGN theNode = theNode:Parent.
END PROCEDURE.

This issue probably needs to be renamed since it neither relates to TREEVIEW, nor to PARENT call.

Vladimir, see annotations/ocx_conversions.rules, line 536 I think. That part is missing function parameters.

         <!-- 2: Change DEFINE VARIABLE chCtrlFrame AS COMPONENT-HANDLE to
                        DEFINE VARIABLE hWidget AS COMPONENT-HANDLE.  or
                        DEFINE VARIABLE hWidget AS HANDLE.  or
                        DEFINE INPUT PARAMETER h AS COMPONENT-HANDLE to
                        DEFINE INPUT PARAMETER h AS HANDLE. -->
         <rule>type == prog.symbol                  and
               parent.parent.type == prog.statement and
               (parent.type == prog.define_variable and (cfh2th.containsKey(text.toUpperCase()) or ch2th.containsKey(text.toUpperCase())) or
                parent.type == prog.define_parameter and ch2th.containsKey(text.toUpperCase()))

There may be other places where function parameters need to be fixed.

• the test for function parameters needs to be like upPath("KW_FUNCT/LPARENS/PARAMETER/SYMBOL") plus a test for the parent to have the vardef annotation set to true. You are currently checking parent.parent.parent.type == prog.kw_funct which is kind of risky.
• please remove the commented code from lines 534-560, there is no need to keep it.

Constantin Asofiei wrote:

Review for 3821c/12930:

• the test for function parameters needs to be like upPath("KW_FUNCT/LPARENS/PARAMETER/SYMBOL") plus a test for the parent to have the vardef annotation set to true. You are currently checking parent.parent.parent.type == prog.kw_funct which is kind of risky.
• please remove the commented code from lines 534-560, there is no need to keep it.

The path in the argiment to upPath should not include SYMBOL. Also, I've added the test for this parameter name was registered in .ext-hints:

ch2th.containsKey(text.toUpperCase())

The result is committed as rev. 12932. Please review.

Vladimir Tsichevski wrote:

The result is committed as rev. 12932. Please review.

I'm OK with the change.