FWD » Core Development » Conversion Tools

Empty arguments of converted OCX method invocations are converted into "unknown" instances.

For example the following 4GL assignment

hNode = chCfTreeView:TreeView:Nodes:Add(,,cParentNodeID,"Root node").

is converted to:

hNode.assign(hTree.unwrapTreeView().getNodes().unwrapTreeNodeCollection().add(new integer(), new integer(), cParentNodeId, new character("Root node")));

It is reasonable to believe that this is incorrect, instead of unknown values the arguments should be "zero" values (or even something else).

Create a set of test cases to find out how OE converts empty arguments and modify the conversion rules accordingly.

The function parameter specification in COM type library may contain a default value. Perhaps this is the value used by OE when an empty argument is given. How does OE behave when no defaults are given in the type library?

FYI: see testcases/oxc_to_fwd/mscomctl-treeview-ocx.w :
hNode = chCfTreeView:TreeView:Nodes:Add(,,cParentNodeID,"Root node").

The following is also valid ABL syntax (identical):
hNode = chCfTreeView:TreeView:Nodes:Add(?,?,cParentNodeID,"Root node").

The OpenEdge documentation states explicitly that it's up to the OCX if a parameter is 0 or 1 based, not simply 1-based like the 4GL. And that a 4GL developer must take care of that himself.
The 4GL unknown value (?) translates to null.
It's up to the OCX (and the 4gl runtime) to do something with that.

The following magic number '4' creates a child node:
chCfTreeView:TreeView:Nodes:Add(hNode,4,cChildNodeID,"Child node").

Also see the readme in xfer testcases (next to the source above).

Hynek Cihlar wrote:

hNode.assign(hTree.unwrapTreeView().getNodes().unwrapTreeNodeCollection().add(new integer(), new integer(), cParentNodeId, new character("Root node")));

It is reasonable to believe that this is incorrect, instead of unknown values the arguments should be "zero" values (or even something else).

On first glance, I think the conversion is correct. Zero should not be used I think, that is a value. A sentinel value (null, ellipsis, ...) could make sense.

This issue must be fixed along with: #5622-12. Otherwise no compilable code is created by conversion for this call.

Vladimir Tsichevski wrote:

Seems, I was not right here: undefined values can be used by OE to pass the "default" value to OCX. Moreover, undefined values are expected by OCX in some situations, for example, it must be passed as the parent node reference when creating the first node in the tree.

But the critical issue referenced in #5622-12 is still to be fixed.

Agree.
Nitpick/terminology: The ABL protects against undefined variables. A variable is never uninitialized. If initialized with the unknown value, that's semantically the same as initialized with null/nill/none in other languages. The unknown value is not undefined.
Sorry if that sounded pedantic. Just to take away possible confusion. Please inform me if FWD terminology differs.

Tijs Wickardt wrote:

Vladimir Tsichevski wrote:

Seems, I was not right here: undefined values can be used by OE to pass the "default" value to OCX. Moreover, undefined values are expected by OCX in some situations, for example, it must be passed as the parent node reference when creating the first node in the tree.

But the critical issue referenced in #5622-12 is still to be fixed.

Agree.
Nitpick/terminology: The ABL protects against undefined variables. A variable is never uninitialized. If initialized with the unknown value, that's the same as initialized with null/nill/none in other languages. The unknown value is not undefined.
Sorry if that sounded pedantic. Just to take away possible confusion.

Completely agreed. I must use the unknown term everywhere, sorry for the confusion.

Tijs Wickardt wrote:

The OpenEdge documentation states explicitly that OCX's are 0-based, not 1-based like the 4GL.

The first argument of the original treeview OCX add call is 1-based node index. This means the first tree node you create has the index 1. And this has no any connection with 4gl.

Tijs Wickardt wrote:

FYI: see testcases/oxc_to_fwd/mscomctl-treeview-ocx.w :
hNode = chCfTreeView:TreeView:Nodes:Add(,,cParentNodeID,"Root node").

The following is also valid ABL syntax (identical):
hNode = chCfTreeView:TreeView:Nodes:Add(?,?,cParentNodeID,"Root node").

It must be identical, but it is not in FWD, as the latest experiments show:

The following code contains 6 calls, which are effectively should execute the same in runtime:

nodes:Add(?, 4, "Key", "Label", img1, img2).
nodes:Add(?, ?, "Key", "Label", img1, img2).
nodes:Add(?, ?, ?, "Label", img1, img2).

nodes:Add(, 4, "Key", "Label", img1, img2).
nodes:Add(, , "Key", "Label", img1, img2).
nodes:Add(, , , "Label", img1, img2).

Currently FWD converts them incorrectly and differently:

         nodes.unwrapTreeNodeCollection().add(new integer(4), new character("Key"), new character("Label"), img1, img2);
         nodes.unwrapTreeNodeCollection().add(new character("Key"), new character("Label"), img1, img2);
         nodes.unwrapTreeNodeCollection().add(new character("Label"), img1, img2);
         nodes.unwrapTreeNodeCollection().add(new integer(), new integer(4), new character("Key"), new character("Label"), img1, img2);
         nodes.unwrapTreeNodeCollection().add(new integer(), new integer(), new character("Key"), new character("Label"), img1, img2);
         nodes.unwrapTreeNodeCollection().add(new integer(), new integer(), new character(), new character("Label"), img1, img2);

As you may see, OCX method calls with omitting parameters are converted correctly, while the call where unknown literals explicitly passed as parameters, are converted incorrectly: these parameters are just missing in the output!

Vladimir Tsichevski wrote:

Tijs Wickardt wrote:

The OpenEdge documentation states explicitly that OCX's are 0-based, not 1-based like the 4GL.

The first argument of the original treeview OCX add call is 1-based node index. This means the first tree node you create has the index 1. And this has no any connection with 4gl.

I didn't describe it correctly, sorry about that.
It's up to the OCX if a parameter is 0 or 1 based.

The .ast file seems to be correct (all parameters in the call are present, but in .jast file parameters for the ? literal are missing. I gather, the problem is in generating Java from .ast.

Can anybody point me to the rule files responsible for generation Java?
Thanks.

Vladimir Tsichevski wrote:

The .ast file seems to be correct (all parameters in the call are present, but in .jast file parameters for the ? literal are missing. I gather, the problem is in generating Java from .ast.

Can anybody point me to the rule files responsible for generation Java?
Thanks.

Add -Drules.tracing to the ConversionDriver java process. With rules tracing on, you will see the rule file and line on every node or annotation where it originated. This will help you to get to the rules responsible for the argument expressions.

Vladimir, is there a customer app failing test case for this? If not I suggest you make this lower priority.