FWD » Core Development » User Interface

See https://docs.microsoft.com/en-us/windows/desktop/controls/progress-bar-control-reference for documentation. This is a pretty simple progress indicator.

From Hynek:

While the progress bar control is indeed primitive, the actual effort may depend on the visual style(s) we choose to implement. For example one of the visual styles uses gradients to draw the progress bar, AFAIK we don't support gradients in the GUI drivers.

Vladimir recently encountered similar problems, please see #3820 for some useful notes.

I suspect you are right that the MS VB dev tools must be installed to provide that control to the Appbuilder.

I created an UAST test progressbar-demo.w starting from an existing UAST test for PSTime OCX but using the ProgressBar OCX properties, methods and events.
I used the ABL Procedure Editor window option Compile/Check Syntax to validate the code and I've got no errors.
On my WM I found a wrx file at C:\Progress\OE116_64\gui\webutil\_probar.wrx which is for a ProgressBar VB 5.0 common control.
Unfortunately using this file we still cannot execute the test due to missing license for MS Common Controls on VM machine.

Next I tried to convert the test in FWD and it was converted without errors because we already have a generic scaffold to handle COM objects implemented by Ovidiu.
However reading the wiki page for TreeView widget implemented by Hynek, I saw that he implemented the OCX like a 4gl widget (FWD extension) which is a substitute for control frame
defining additional rules for conversion in ocx_conversion.rules
I think that is a best way to follow for all OCX components replacements including the ProgressBar OCX FWD implementation.

created task branch 3858a rev 11328

From Marius:

• I did the changes in the conversion rules for ProgressBar widget following the same rules like already implemented TreeView, HtmlBrowse widgets. My changes has been committed in 3858a/11329
• I created a simple UAST test to create a ProgressBar widget without properties, methods and events.
• I created a <test_file_name.p>.ext-hints file for my test as I found in ocx_conversion.rules.
• I tried to convert my UAST test but did not work due to a NPE!
  

  com.goldencode.p2j.pattern.TreeWalkException: ERROR! Active Rule:
          -----------------------
                RULE REPORT
          -----------------------
          Rule Type :   WALK
          Source AST:  [ pbProgBar ] BLOCK/STATEMENT/CREATE_WIDGET/VAR_HANDLE/ @0:0 {12884902245}
          Copy AST  :  [ pbProgBar ] BLOCK/STATEMENT/CREATE_WIDGET/VAR_HANDLE/ @0:0 {12884902245}
          Condition :  ref.isAnnotation("extent")
          Loop      :  false
          --- END RULE REPORT ---
  
              at com.goldencode.p2j.pattern.PatternEngine.run(PatternEngine.java:1070)
              at com.goldencode.p2j.convert.TransformDriver.processTrees(TransformDriver.java:540)
              at com.goldencode.p2j.convert.ConversionDriver.back(ConversionDriver.java:580)
              at com.goldencode.p2j.convert.TransformDriver.executeJob(TransformDriver.java:874)
              at com.goldencode.p2j.convert.ConversionDriver.main(ConversionDriver.java:983)
          Caused by: java.lang.NullPointerException
              at com.goldencode.expr.CE10663.execute(Unknown Source)
              at com.goldencode.expr.Expression.execute(Expression.java:373)
  

• So far, debugging the code in *.rules cannot help me to find the cause. Seems that is not from code in ocx_conversion.rules
• I found that Ovidiu also provide a way to convert generic ocx's using extension hints.
• I tried such a conversion and I succeeded but without honoring the drop-procedure hint.
• He created a custom conversion set of rules special for the PSTimer OCX.
• Now I'm a little bit confused. Which is the best way to follow, the rules for TreeView, HtmlBrowse or for a generic ocx?

I think you should branch from 4124a because the OCX conversion is heavily modified and enhanced in that branch. For example, Ovidiu's previous code is no longer there. We are trying to get it into the trunk ASAP, but you should work "on top" of 4124a for the next few days.

I rebased my task branch 3858a from branch 4124a

Marius, could you please attach the 4gl example, which causes troubles?

I work on another OCX widget, and at the moment I have no problem with converting and running it.

PS: my branch is 3820a, it was created by merging the 4124a, rev. 11329, and the trunk branch at 2019-09-04.

After the merge, I have fixed the COM-related runtime a lot, but I never had any problem with conversion.

Marius Gligor wrote:

Vladimir, I attached both the uast test and ext-hints file.

The problem is in the target-widget="progress-bar" in the progress_bar_test.p.ext-hints. You probably should ask Hynek, why is this.

You can try the following:

1. Replace the line

        UIB_S = chCtrlFrame:LoadControls(OCXFile, "CtrlFrame":U).

by

        UIB_S = chCtrlFrame:LoadControls(OCXFile, "MyClass":U).

where MyClass is the name of your OCX widget.

2. Remove the progress_bar_test.p.ext-hints from your project.

Vladimir, many thanks for your feedback.
Without ext-hints file the conversion is done with success but the result is not what I expect.
Basically the conversion is done like in the initial implementation without replacing the CONTROL-FRAME with CREATE <widget>
I need to implement the ProgressBar like a 4Gl widget extension.
I have to talk with Hynek, I'm going to write a mail to him.

Marius Gligor wrote:

I need to implement the ProgressBar like a 4Gl widget extension.

Ok, now I see that.

I have to talk with Hynek, I'm going to write a mail to him.

You probably should.

Marius, regrading the NPE. Did you extend widgetKwords and widgetClasses maps in ocx_conversion.rules with the keyword id and the widget class?

Hi Hynek, Yes I did. Please take a look over my changes in branch 3858a (at the top)

 <action>widgetKwords.put("PROGRESS-BAR", prog.kw_prog_bar)</action>
 <action>widgetClasses.put("PROGRESS-BAR", classForName("com.goldencode.p2j.ui.ProgressBar"))</action>

Please see my changes in branch 3858a at the top, I did a single commit so far.

Marius Gligor wrote:

Hi Hynek, Yes I did. Please take a look over my changes in branch 3858a (at the top)

[...]

Please see my changes in branch 3858a at the top, I did a single commit so far.

The problem was with the control frame's com handle variable set to control-frame-handle in the ext-hints file. The value must be set to chCtrlFrame. Also the com-handle value should be something like chCtrlFrame:ProgressBar (depending on the name of the loaded com component in the control frame).

Hynek Cihlar wrote:

Marius Gligor wrote:

Hi Hynek, Yes I did. Please take a look over my changes in branch 3858a (at the top)

[...]

Please see my changes in branch 3858a at the top, I did a single commit so far.

The problem was with the control frame's com handle variable set to control-frame-handle in the ext-hints file. The value must be set to chCtrlFrame. Also the com-handle value should be something like chCtrlFrame:ProgressBar (depending on the name of the loaded com component in the control frame).

I did the changes and now the conversion works properly. Thanks once again.

I'm working to make changes in the rules for ProgressBar events conversion. So far I did changes for mouse events.
I have a question regarding mouse events conversion.

For example ProgressBar OCX define a MouseDown event as follow:

PROCEDURE CtrlFrame.ProgressBar.MouseDown : 
    DEFINE INPUT PARAMETER Button AS INTEGER.
    DEFINE INPUT PARAMETER Shift AS INTEGER.
    DEFINE INPUT PARAMETER x AS INTEGER.
    DEFINE INPUT PARAMETER y AS INTEGER.
    MESSAGE "MouseDown!".
END PROCEDURE.

This is a generic event handler having the mouse button as a parameter.
However in FWD I found specific events for each mouse button: LEFT-MOUSE-DOWN, MIDDLE-MOUSE-DOWN and RIGHT-MOUSE-DOWN
The converted Java code looks like:

registerTrigger(new EventList("LEFT-MOUSE-DOWN", hProgressBar), ProgressBarTest1.this, () -> new Trigger()
         {
            integer y = TypeFactory.integer();
            integer x = TypeFactory.integer();
            integer shift = TypeFactory.integer();
            integer button = TypeFactory.integer();

            public void body()
            {
               y.assign(hProgressBar.unwrapProgressBar().getMouseY());
               x.assign(hProgressBar.unwrapProgressBar().getMouseX());
               shift.assign(hProgressBar.unwrapProgressBar().getMouseShift());
               button.assign(hProgressBar.unwrapProgressBar().getMouseButton());
               ControlFlowOps.invokeWithMode("CtrlFrame.ProgressBar.MouseDown", "IIII", button, shift, x, y);
            }
         });

   public void ctrlFrameDotProgressBarDotMouseDown(final integer _button, final integer _shift, final integer _x, final integer _y)
   {
      integer button = UndoableFactory.initInput(_button);
      integer shift = UndoableFactory.initInput(_shift);
      integer x = UndoableFactory.initInput(_x);
      integer y = UndoableFactory.initInput(_y);

      internalProcedure(new Block((Body) () -> 
      {
         message("MouseDown!");
      }));
   }

The same pattern code apply for other mouse events as well.

The question is:
Should we register triggers for all LEFT-MOUSE-DOWN, MIDDLE-MOUSE-DOWN and RIGHT-MOUSE-DOWN events or we could define a generic MOUSE-DOWN event?

created new task branch 3858b from trunk and cherry-picked changes for PROGRESS-BAR widget implementation from 3858a

Task branch 3858b has been rebased with trunk 11330, new revision is 11337.
Task branch 3858a has been archived, moved to merged folder. I'm not sure but maybe the dead folder is the right place for this branch.

I moved 3858a to dead from merged.

I've fixed a bug in OCX conversion for events regarding to procedure parameters type which can be INPUT, OUTPUT or INPUT-OUTPUT.
When the event handler is called in the converted code, the mode argument should have correct values: I, O or U.
The mode parameter is set depending on the parameter type.

    
   ControlFlowOps.invokeWithMode("CtrlFrame.ProgressBar.OLECompleteDrag", "U", effect);
   ControlFlowOps.invokeWithMode("CtrlFrame.ProgressBar.MouseUp", "IIII", button, shift, x, y); 

Hynek Cihlar wrote:

Marius Gligor wrote:

2. Next, I added Mouse Events support to Progress Bar widget. Here I found a conversion issue. Let me to explain:
Bellow is snippet code form my uast test:

[...]

The ProgressBar events are converted into triggers and the generated Java code looks like:

[...]

Btw, why don't you use the standard MOUSE-CLICKED event?

Progress bar OCX mouse events are generic, the mouse button is an input parameter, that's why I need a generic MOUSE-DOWN event for example, instead specific LEFT-MOUSE-DOWN, MIDDLE-MOUSE-DOWN and RIGHT-MOUSE-DOWN events.
I found no such generic events defined in FWD yet, that's why I defined new generic events OCX-MOUSE-XXX. I could remove the OCX_ prefix to make the definition even more generic.
Please see 9 and 25 notes.

Marius Gligor wrote:

Progress bar OCX mouse events are generic, the mouse button is an input parameter, that's why I need a generic MOUSE-DOWN event for example, instead specific LEFT-MOUSE-DOWN, MIDDLE-MOUSE-DOWN and RIGHT-MOUSE-DOWN events.
I found no such generic events defined in FWD yet, that's why I defined new generic events OCX-MOUSE-XXX. I could remove the OCX_ prefix to make the definition even more generic.
Please see 9 and 25 notes.

I think it makes sense to introduce the generic mouse event. To read the async mouse and key states put a suitable set of methods in a place that can be accessed by any widget (or eventually 4gl logic), possibly to LogicalTermial.

Also see KeyReader.getLastKeyState and KeyReader.getLastKey. These should already return the last key states.

I could remove the OCX_ prefix to make the definition even more generic.

Yes, this would be good.

Some OCX Progress Bar event handlers for Drag & Drop operations are using a parameter of type COM-HANDLE:

PROCEDURE CtrlFrame.ProgressBar.OLEStartDrag : 
    DEFINE INPUT-OUTPUT PARAMETER Data AS COM-HANDLE.  /* IVBDataObject */
    DEFINE INPUT-OUTPUT PARAMETER AllowedEffects AS INTEGER.
END PROCEDURE.

The Data AS COM-HANDLE is a handle of a IVBDataObject COM Interface. Searching over Internet I found a VB description of this interface:

' Interface Name  : IVBDataObject
' Class Name      : DataObject
' ClassID         : $CLSID_DataObject
' This Interface cannot be created directly it can only
' be returned by a Method or Property in this library.
Interface IVBDataObject $IID_IVBDataObject
  Inherit IDispatch

  Method Clear <1> ()
  Method GetData <2> (Byval sFormat As Integer) As Variant
  Method GetFormat <3> (Byval sFormat As Integer) As Integer
  Method SetData <4> (Opt Byval vValue As Variant, Opt Byval vFormat As Variant)
  Property Get Files <5> () As IVBDataObjectFiles
End Interface

' Interface Name  : IVBDataObjectFiles
' Class Name      : DataObjectFiles
' ClassID         : $CLSID_DataObjectFiles
' This Interface cannot be created directly it can only
' be returned by a Method or Property in this library.
Interface IVBDataObjectFiles $IID_IVBDataObjectFiles
  Inherit IDispatch

  Property Get Item <0> (ByVal lIndex As Long) As WString
  Property Get Count <1> () As Long
  Method Add <2> (Byval bstrFilename As WString, Opt Byval vIndex As Variant)
  Method Clear <3> ()
  Method Remove <4> (Byval vIndex As Variant)
  Method Meth__NewEnum <-4> () As IUnknown
End Interface

Actually they are 2 COM interfaces IVBDataObject and IVBDataObjectFiles Those interfaces are used as a storage for Drag & Drop operations.
My question is: Should we implement these interfaces as FWD ComObject objects and accessed via comhandle or we have to find another solution in which use handle instead comhandle?
I already added an option to replace the comhandle with handle for those parameters. Using the handle we have to implements COM interfaces inside the widget code.

Marius Gligor wrote:

My question is: Should we implement these interfaces as FWD ComObject objects and accessed via comhandle or we have to find another solution in which use handle instead comhandle?
I already added an option to replace the comhandle with handle for those parameters. Using the handle we have to implements COM interfaces inside the widget code.

I faced the same problem when I was working on conversion of MS Tree COM control. Among others the control exposes Node sub-object. I converted this to its own legacy resource. See TreeViewNode, LegacyResource.TREEVIEW_NODE, TreeViewNodeResource and related classes. This way the Node comhandle converts to handle and is accessed as any other legacy resource.

The problem you will face is that the handle must be unwrapped to a type that must be known during conversion. Currently the unwrapping happens based on the accessed property or method name. The names in your interfaces are pretty generic, so you may get conflicts. You will have to either obfuscate the method/prop names or derive new interfaces to capture the conflicting methods/props.

Hynek Cihlar wrote:

Marius Gligor wrote:

My question is: Should we implement these interfaces as FWD ComObject objects and accessed via comhandle or we have to find another solution in which use handle instead comhandle?
I already added an option to replace the comhandle with handle for those parameters. Using the handle we have to implements COM interfaces inside the widget code.

I faced the same problem when I was working on conversion of MS Tree COM control. Among others the control exposes Node sub-object. I converted this to its own legacy resource. See TreeViewNode, LegacyResource.TREEVIEW_NODE, TreeViewNodeResource and related classes. This way the Node comhandle converts to handle and is accessed as any other legacy resource.

The problem you will face is that the handle must be unwrapped to a type that must be known during conversion. Currently the unwrapping happens based on the accessed property or method name. The names in your interfaces are pretty generic, so you may get conflicts. You will have to either obfuscate the method/prop names or derive new interfaces to capture the conflicting methods/props.

Hynek, many thanks for your hints. I'm looking to use a similar solution thinking that IVBDataObject and IVBDataObjectFiles COM interfaces are common for all ActiveX which support Drag & Drop operations, not only for Progress Bar.

Marius Gligor wrote:

It's possible to insert an AST node before another node, when both are siblings nodes?

You can move a node with Aast.move().

There might be issues in Hotel GUI, this is meant (for now) to work with 4069a.

1. I've finished to write the PROGRESS-BAR widget documentation
(Progress Indicator Widget and OCX Replacement).

I have a small observation regarding conversion extension hints.
For TREEVIEW is specified:

<extension>
   <ocx control-frame="CtrlFrame" control-frame-handle="chCtrlFrame" control="tree" target-handle="hTree" />
   <drop-procedure name="control_load" />
</extension>

But for PROGRESS-BAR I used:

<extension>
   <ocx control-frame="CtrlFrame" control-frame-handle="chCtrlFrame" com-handle="chCtrlFrame:ProgressBar" target-handle="hProgressBar" target-widget="progress-bar" />
   <drop-procedure name="control_load" />
</extension>

The difference is control attribute for TREEVIEW but target-widget for PROGRESS-BAR!
Looking inside ocx_conversion.rule file I found:

<!-- gather the list of OCXs-->
<rule>xmlNode.text.equals("ocx")
  <action>cfName  = xml.getAttributeValue(xmlNode, "control-frame")</action>
  <action>cfhName = xml.getAttributeValue(xmlNode, "control-frame-handle")</action>
  <action>chName  = xml.getAttributeValue(xmlNode, "com-handle")</action>
  <action>wType   = xml.getAttributeValue(xmlNode, "target-widget")</action>
  <action>thName  = xml.getAttributeValue(xmlNode, "target-handle")</action>

Seems that in the mean time control attribute has been replaced by target-widget. Maybe we have to update the documentation for TREEVIEW as well.

2. Searching in the VM AsiGUI I found a progress bar OCX procedure _probar.w together with a _probar.wrx file. I created and successfully converted an uast test from this one.
Unfortunately looking over the code I found that is a very simple use of Progress Bar OCX, default properties and only update the Value property.
No mouse events, no OLE Drag & Drop events. Progress Bar OCX widget is very simple and perhaps minimum features are used.

The implementation for PROGRESS-BAR widget in branch 3858b is ready for a first code review.

Marius, note that drop-procedure is no longer part of the conversion logic. Removing the init method was problematic, there were cases where the ocxes were loaded from arbitrary places and where the init method contained additional useful statements.

The OCX loading logic must be currently guarded by FWD-VERSION preproccesor variable.

Hynek: Please do a code review.

Vladimir Tsichevski wrote:

I was trying to convert and run the progressbar demo application:

1. Obtained the latest 3856b branch for conversion and runtime;
2. Obtained the latest demo from testcases/uast/progressbar (progressbar-demo.w and progress_bar_test.p.ext-hints);
3. Created an empty dummy pbar.wrx file;

I've got a NPE when converting (see the log attached).

I successfully converted following tests:

./image-list/image_list_test1.p
./image-list/image_list_test2.p
./image-list/image_list_test3.p
./image-list/image_list_test4.p
./progressbar/progress_bar_test1.p
./progressbar/progress_bar_test2.p
./progressbar/progress_bar_test3.p
./progressbar/progress_bar_test4.p
./progressbar/progress_bar_test5.p
./progressbar/progress_bar_test6.p
./progressbar/progressbar-demo.w

prepare:
    [mkdir] Created dir: /home/mag/gcd/testcases/uast/build
    [mkdir] Created dir: /home/mag/gcd/testcases/uast/build/lib
    [mkdir] Created dir: /home/mag/gcd/testcases/uast/build/classes
     [copy] Copying 1 file to /home/mag/gcd/testcases/uast/build/classes
     [copy] Copying 17 files to /home/mag/gcd/testcases/uast/build/classes
     [copy] Copying 2 files to /home/mag/gcd/testcases/uast/build/classes
     [copy] Copying 1 file to /home/mag/gcd/testcases/uast/build/classes
     [copy] Copying 3 files to /home/mag/gcd/testcases/uast/build/classes/cfg
     [copy] Copying 4 files to /home/mag/gcd/testcases/uast/build/classes/data

compile:
    [javac] Compiling 50 source files to /home/mag/gcd/testcases/uast/build/classes
     [echo] Compiling Java Sources Done.

jar:
      [jar] Building jar: /home/mag/gcd/testcases/uast/build/lib/testcases.jar

BUILD SUCCESSFUL
Total time: 53 seconds
mag@mag-N751JK:~/gcd$ 

Please use these tests. You should have both <test>.p and <test>p.ext-hints files. You don't need to create a .wrx file.

Please check if you have the correct link to p2j project in testcases/uast
ln -s $HOME/<your branch location>/3856b/ p2j
Using a wrong link could cause a NPE exception.
Also do a build of 3856b branch before starting the conversion.

Marius Gligor wrote:

Please use these tests. You should have both <test>.p and <test>p.ext-hints files. You don't need to create a .wrx file.

Please check if you have the correct link to p2j project in testcases/uast
ln -s $HOME/<your branch location>/3856b/ p2j
Using a wrong link could cause a NPE exception.
Also do a build of 3856b branch before starting the conversion.

The progressbar-demo.w.ext-hints is missing in the repository. I copied it from other hint file in the same directory first, but it was a mistake, since the name of the handle in progressbar-demo.w differs from that in all other tests.

I fixed the name in the hint file, and now the demo compiles Ok.

I think, you just forgot to add this hint file to the repository.

For the progressbar-demo.w conversion produces uncompilable Java:

The line:

RELEASE OBJECT pbCOM.

converts to:

ComServer.release(hProgressBar);

which causes the following compilation error:

    [javac] /home/vvt/Projects/test3856b/src/com/test3856b/Test.java:58: error: incompatible types: handle cannot be converted to comhandle
    [javac]          ComServer.release(hProgressBar);
    [javac]                            ^

After I have the offending RELEASE OBJECT commented, the demo compiles Ok, but running it causes no window displayed, and this endless output:

client:
     [java] SLF4J: Class path contains multiple SLF4J bindings.
     [java] SLF4J: Found binding in [jar:file:/home/vvt/p2j/branches/3856b/build/lib/slf4j-jdk14-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
     [java] SLF4J: Found binding in [jar:file:/home/vvt/p2j/branches/3856b/build/lib/slf4j-simple-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
     [java] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
     [java] SLF4J: Actual binding is of type [org.slf4j.impl.JDK14LoggerFactory]
     [java] UI Theme successfully changed to 'material'
     [java] DRAW: Ignoring event com.goldencode.p2j.ui.client.event.PaintEvent 9 raised while drawing widget com.goldencode.p2j.ui.client.gui.CaptionButton with id [-10].
     [java] Dec 05, 2019 1:05:49 AM com.goldencode.p2j.ui.client.event.EventManager postEvent
     [java] WARNING: Wasted event: com.goldencode.p2j.ui.client.event.PaintEvent@bcc2dcfa
     [java] DRAW: Ignoring event com.goldencode.p2j.ui.client.event.PaintEvent 9 raised while drawing widget com.goldencode.p2j.ui.client.gui.CaptionButton with id [-10].
     [java] Dec 05, 2019 1:05:50 AM com.goldencode.p2j.ui.client.event.EventManager postEvent
     [java] WARNING: Wasted event: com.goldencode.p2j.ui.client.event.PaintEvent@c6d2d20
     [java] DRAW: Ignoring event com.goldencode.p2j.ui.client.event.PaintEvent 9 raised while drawing widget com.goldencode.p2j.ui.client.gui.CaptionButton with id [-10].
...

Vladimir Tsichevski wrote:

Marius Gligor wrote:

Please use these tests. You should have both <test>.p and <test>p.ext-hints files. You don't need to create a .wrx file.

Please check if you have the correct link to p2j project in testcases/uast
ln -s $HOME/<your branch location>/3856b/ p2j
Using a wrong link could cause a NPE exception.
Also do a build of 3856b branch before starting the conversion.

The progressbar-demo.w.ext-hints is missing in the repository. I copied it from other hint file in the same directory first, but it was a mistake, since the name of the handle in progressbar-demo.w differs from that in all other tests.

I fixed the name in the hint file, and now the demo compiles Ok.

I think, you just forgot to add this hint file to the repository.

Indeed I forgot to push progressbar-demo.w.ext-hints I'will fix that

Vladimir Tsichevski wrote:

For the progressbar-demo.w conversion produces uncompilable Java:

The line:
[...]

converts to:

[...]

which causes the following compilation error:

[...]

progressbar-demo.w is an early test created "by hand" because we cannot use OpenEdge environment to create tests for Microsoft VB 6.0 common control due to missing the valid license.
Original statement: RELEASE OBJECT chCtrlFrame. is converted into Java as ComServer.release(hProgressBar); but after conversion chCtrlFrame
of type COM-HANDLE is converted into hProgressBar which is of type HANDLE
The solution is to completely remove the statement RELEASE OBJECT chCtrlFrame. at conversion time.

Vladimir Tsichevski wrote:

After I have the offending RELEASE OBJECT commented, the demo compiles Ok, but running it causes no window displayed, and this endless output:

[...]

Not all tests are designed to show the main window. progress_bar_test.p as an early test was designed to test conversion only.
If you take a look inside ABL code we don't have any wait statement.
As a result when we run the test he is executed and then exit because we don't have a wait statement.

Marius Gligor wrote:

The solution is to completely remove the statement RELEASE OBJECT chCtrlFrame. at conversion time.

I think the RELEASE OBJECT statement should be converted to DELETE OBJECT.

Hynek Cihlar wrote:

Marius Gligor wrote:

The solution is to completely remove the statement RELEASE OBJECT chCtrlFrame. at conversion time.

I think the RELEASE OBJECT statement should be converted to DELETE OBJECT.

Yes, good point, DELETE OBJECT is the correct replacement.

Marius Gligor wrote:

Not all tests are designed to show the main window. progress_bar_test.p as an early test was designed to test conversion only.
If you take a look inside ABL code we don't have any wait statement.
As a result when we run the test he is executed and then exit because we don't have a wait statement.

I am trying to run the progressbar-demo.w from the testcases. It ends with:

WAIT-FOR CLOSE OF DEFAULT-WINDOW.

And it is designed to run tests and display multiple messages.

Vladimir Tsichevski wrote:

Marius Gligor wrote:

Not all tests are designed to show the main window. progress_bar_test.p as an early test was designed to test conversion only.
If you take a look inside ABL code we don't have any wait statement.
As a result when we run the test he is executed and then exit because we don't have a wait statement.

I am trying to run the progressbar-demo.w from the testcases. It ends with:

[...]

And it is designed to run tests and display multiple messages.

You can try to convert and run progress_bar_test3.p and progress_bar_test4.p which are more complex and allow you to interact with the progress bar widget using some buttons and you can test also mouse events.

I added rules to convert RELEASE OBJECT into DELETE OBJECT and I converted my uast test

I have the following ABL statements in the test:

RELEASE OBJECT chCtrlFrame.
DELETE OBJECT CtrlFrame.

HandleOps.delete(hProgressBar);
HandleOps.delete(hProgressBar);

Marius Gligor wrote:

I added rules to convert RELEASE OBJECT into DELETE OBJECT and I converted my uast test

I do not see any updates in 3856b :(

I have the following ABL statements in the test:
[...]
which are converted in Java as follow:
[...]
As you can see we have the same statement twice. I think that a better solution is to cut off RELEASE OBJECT chCtrlFrame. statement
at conversion time. That's because I think the pair statements RELEASE and DELETE are always present in the code together.

I am not sure, but I think, the RELEASE is used for COM handles, and DELETE for ordinary handles, so the will never be presented simultaneously? So only the RELEASE statement should left in the OCX-based sources.

Marius Gligor wrote:

You can try to convert and run progress_bar_test3.p and progress_bar_test4.p which are more complex and allow you to interact with the progress bar widget using some buttons and you can test also mouse events.

Then, I think, in order to prevent any confusion in the future, the progressbar-demo.w shall either be fixed, or removed from the repository completely.

Vladimir Tsichevski wrote:

Marius Gligor wrote:

I added rules to convert RELEASE OBJECT into DELETE OBJECT and I converted my uast test

I do not see any updates in 3856b :(

I have the following ABL statements in the test:
[...]
which are converted in Java as follow:
[...]
As you can see we have the same statement twice. I think that a better solution is to cut off RELEASE OBJECT chCtrlFrame. statement
at conversion time. That's because I think the pair statements RELEASE and DELETE are always present in the code together.

I am not sure, but I think, the RELEASE is used for COM handles, and DELETE for ordinary handles, so the will never be presented simultaneously? So only the RELEASE statement should left in the OCX-based sources.

If we keep only RELEASE we have to transform into DELETE, but another possible solution is to keep both if not raise runtime problems.
I have to check what's happen at runtime when we execute HandleOps.delete(hProgressBar); twice.

Marius Gligor wrote:

If we keep only RELEASE we have to transform into DELETE, but another possible solution is to keep both if not raise runtime problems.
I have to check what's happen at runtime when we execute HandleOps.delete(hProgressBar); twice.

Also consider more complicated cases. Like passing a comhandle to an external procedure and releasing it there.

Hynek Cihlar wrote:

Marius Gligor wrote:

If we keep only RELEASE we have to transform into DELETE, but another possible solution is to keep both if not raise runtime problems.
I have to check what's happen at runtime when we execute HandleOps.delete(hProgressBar); twice.

Also consider more complicated cases. Like passing a comhandle to an external procedure and releasing it there.

In that case I'm affraid we have to do changes in the external procedure because we transform com-handle into handle in the current procedure.
Do you see another option?

But when the com-handle is released in the current procedure file we could do as follow.
Before transforming RELEASE into DELETE I always take care to check if the com-handle is defined in .ext-hints file: control-frame-handle="chCtrlFrame" and do the conversion only if com-handle name match.

Even so, unfortunately is not 100% safe. If we have something like:

define variable chCtrlFrame as component-handle no-undo.
...
procedure close_handle :
    define input parameter chCtrlFrame as com-handle.
    ...
    release object chCtrlFrame.
end procedure.

Marius Gligor wrote:

Hynek Cihlar wrote:

Marius Gligor wrote:

If we keep only RELEASE we have to transform into DELETE, but another possible solution is to keep both if not raise runtime problems.
I have to check what's happen at runtime when we execute HandleOps.delete(hProgressBar); twice.

Also consider more complicated cases. Like passing a comhandle to an external procedure and releasing it there.

In that case I'm affraid we have to do changes in the external procedure because we transform com-handle into handle in the current procedure.
Do you see another option?

There was such a case in one of the customer apps. I added an ext-hints file for the external procedure and removed some assumptions from the rules files to properly convert the comhandle to a handle in the other external procedure. You should test this case as well. Nothing complicated, passing a comhandle and referencing a prop and a method should do it.

In general converting comhandles in other procedure files shouldn't be any different. Only the structure is different - no LoadControls, no control frame handles, etc.

But when the com-handle is released in the current procedure file we could do as follow.
Before transforming RELEASE into DELETE I always take care to check if the com-handle is defined in .ext-hints file: control-frame-handle="chCtrlFrame" and do the conversion only if com-handle name match.

This makes sense.

Even so, unfortunately is not 100% safe. If we have something like:
[...]
it is a problem. It's less probable to have this pattern but is not zero.

IMHO this could be covered with the same rules. There just could be additional variables.

Code review 3856b. I only have a few minor points.

• The aliases for TREELIST must also include TREEVIEW aliases.
• Regarding dropping the init procedure. It would be safer to drop the procedure body, than the whole assignment where the procedure is referenced. I've encountered a case where such a drop caused removal of other useful logic.

checkParams in ComObject is never called.

I encountered several places where file history numbering was not correct, for example multiple numbers where there should be only one.

Widget.refreshWidget
The only implementation only forwards the call to repaint(). Why not to call repaint() directly?
Btw, to repaint a widget do:
eventDrawingBracket(widget, widget::repaint)

Similarly as above, for oleDrag use eventDrawingBracket. Btw. if you need the repaints to happen out of the os event loop, you may need to also call processRepaints.

A small formatting issue - conditionals with one line bodies are sometime missing curly braces.

getMoseIconLocation => getMouseIconLocation, also the method should be part of Theme interface and the image resources part of the theme packages.

GWD.mimeType
The method should be moved among other private methods. The input argument should be trimmed and lower-cased.

drawProgressBar and drawProgressBarBar
Params are incorrectly formatted.

ImageListWidget.listImages is missing comment.

ILW.resourceDelete(), global images are already removed on the client as part of widget destroy in AbstractWidget.destroy().

Are OLE-X and OLE-Y in pixels? If so, they should be ints.

OcxMouseHelper class is missing javadoc.

OleDragDrop class is missing javadoc.

OleDragDropHelper.dirty() a good candidate for a common method.

ProgressBarGuiImpl.height() is missing javadoc.

Marius Gligor wrote:

You can try to convert and run progress_bar_test3.p and progress_bar_test4.p which are more complex and allow you to interact with the progress bar widget using some buttons and you can test also mouse events.

I tried all the progressbar tests in the testcases (I removed all the offending RELEASE lines):

1. progressbar-demo.w does not work
2. progress_bar_test.p presumably works, but shows nothing, I think this test shall be removed.
3. progress_bar_test1.p presumably works, but shows nothing, I think this test shall be removed.
4. progress_bar_test2.p demonstrates the horizontal bar capabilities, works perfectly.
5. progress_bar_test3.p demonstrates the vertical bar capabilities, works perfectly.
6. progress_bar_test4.p demonstrates the horizontal bar capabilities, works perfectly. I suppose, it is an advanced version of test2, if so the test2 shall be probably removed.
7. progress_bar_test5.p does not work
8. progress_bar_test6.p demonstrates the horizontal bar capabilities again. I do not see any difference from the test2 and test4 :(
9. progress_bar_test7.p need some arguments to run, but no any description provided on how to run it.

I think, the following shall be done with the tests:

1. remove the test which do not work or make them working
2. remove the duplicate test, if one test is the advanced version of another, remove the less advanced one
3. provide the test names in window titles (now all test window titles are the same or have no meaning)
4. provide a short README describing what is demonstrated in each test.
5. optionally provide a run-all.p which runs all tests in sequence.

Vladimir Tsichevski wrote:

Marius Gligor wrote:

You can try to convert and run progress_bar_test3.p and progress_bar_test4.p which are more complex and allow you to interact with the progress bar widget using some buttons and you can test also mouse events.

I tried all the progressbar tests in the testcases (I removed all the offending RELEASE lines):

1. progressbar-demo.w does not work
2. progress_bar_test.p presumably works, but shows nothing, I think this test shall be removed.
3. progress_bar_test1.p presumably works, but shows nothing, I think this test shall be removed.
4. progress_bar_test2.p demonstrates the horizontal bar capabilities, works perfectly.
5. progress_bar_test3.p demonstrates the vertical bar capabilities, works perfectly.
6. progress_bar_test4.p demonstrates the horizontal bar capabilities, works perfectly. I suppose, it is an advanced version of test2, if so the test2 shall be probably removed.
7. progress_bar_test5.p does not work
8. progress_bar_test6.p demonstrates the horizontal bar capabilities again. I do not see any difference from the test2 and test4 :(
9. progress_bar_test7.p need some arguments to run, but no any description provided on how to run it.

I think, the following shall be done with the tests:

1. remove the test which do not work or make them working
2. remove the duplicate test, if one test is the advanced version of another, remove the less advanced one
3. provide the test names in window titles (now all test window titles are the same or have no meaning)
4. provide a short README describing what is demonstrated in each test.
5. optionally provide a run-all.p which runs all tests in sequence.

If you take a look over the ABL code inside progress_bar_test6.p you will see PROGRESS-BAR widget as a 4gl extension.
Once implemented PROGRESS-BAR can be used as any 4gl widget.

Some code review notes:

Conversion¶

The body of the control_load procedure is completely erased by conversion. Meanwhile, it may originally contain code manually inserted by the programmer, for example, in a large customer application I have seen such code.

All methods are marked as LegacyMethod in the ProgressBar interface. No @ComMethod/@ComProperty is used.
Hence there is no reliable way to tell COM properties from COM methods. It may make things complicated when implementing the #4438 task.

Error checking¶

No error checking is implemented at all for property setters. I can assign any values to any property given that they are either of the compatible type or can silently be converted into a compatible type.

Compiler warnings¶

The @Override annotations are missing in most places where they are appropriate.

Code style¶

4gl example code does not follow the 3-space tab indent convention.

Javadocs¶

1. Mixed style of Javadoc comments: in some cases just the {@inheritDoc} placeholder is used (which is the right thing IMHO), in some other the Javadoc comments copy-pasted from the overridden methods (which is not the right thing).

2. The constructor ProgressBarWidget(boolean dynamic) is described as "Default constructor.", which it is not.
no class Javadoc

3. progBarRefresh(), setProgBarMousePointer(), getMouseIcon(): It is unclear from the Javadoc what do these methods do.

remove the test which do not work or make them working
remove the duplicate test, if one test is the advanced version of another, remove the less advanced one

Vladimir, it is OK to have either of these cases in our testcases/uast/ project if the extra tests have some purpose. In other words, we do not require that all testcases in testcases/uast/ are functional or well factored. In fact, we have many tests that are only useful for looking at parsing or full conversion, but which have no correct runtime behavior.

I agree that it is a good practice to leave behind some comments in that case so that future readers are clear as to the purpose.

Mixed style of Javadoc comments: in some cases just the {@inheritDoc} placeholder is used (which is the right thing IMHO), in some other the Javadoc comments copy-pasted from the overridden methods (which is not the right thing).

You may be right on this, but our current coding standards discourages use of {@inheritDoc}:

Do NOT use @inheritDoc. Having nothing but "@inheritDoc" at the source code level for a method's documentation makes it necessary for a developer to either:

• keep a browser with previously compiled javadoc open alongside the editor; or
• know which superclass to navigate to in order to read the javadoc for a given method.

I guess in an IDE this is not an issue but when processing the source code without specialized tools it becomes an issue. A few of us Luddites don't use IDEs for development. :)

Hynek Cihlar wrote:

• Regarding dropping the init procedure. It would be safer to drop the procedure body, than the whole assignment where the procedure is referenced. I've encountered a case where such a drop caused removal of other useful logic.

Did you fix that?

I'm a little bit confused about drop-procedure option.
1. We have an option to specify drop procedure name in .ext-hint file <drop-procedure name="control_load" /> Is this optional or is mandatory? IMO should be mandatory according with my below description.

2. With this option in place the procedure:

PROCEDURE control_load :
   DEFINE VARIABLE UIB_S    AS LOGICAL    NO-UNDO.
   DEFINE VARIABLE OCXFile  AS CHARACTER  NO-UNDO.

   OCXFile = SEARCH( "pbar.wrx" ).

   IF OCXFile = ? THEN
     OCXFile = SEARCH(SUBSTRING(THIS-PROCEDURE:FILE-NAME, 1,
                        R-INDEX(THIS-PROCEDURE:FILE-NAME, ".":U), "CHARACTER":U) + "wrx":U).

   IF OCXFile <> ? THEN
   DO:
    ASSIGN
        chCtrlFrame = CtrlFrame:COM-HANDLE.
        UIB_S = chCtrlFrame:LoadControls(OCXFile, "ProgressBar":U).
   END.
   ELSE MESSAGE "pbar.wrx" SKIP(1)
                "The binary control file could not be found. The controls cannot be loaded." 
                VIEW-AS ALERT-BOX TITLE "Controls Not Loaded".
END PROCEDURE.

is converted into Java code as follow:

   @LegacySignature(type = Type.PROCEDURE, name = "control_load")
   public void controlLoad()
   {
      internalProcedure(new Block());
   }

which means the procedure is not drooped, instead the original body is replaced by an empty body. Any potential call of this procedure RUN control_load. is converted into ControlFlowOps.invoke("control_load");
Is this behavior OK or we should take care about other things?

BTW I created a small application using Application Builder having a PSTimer OCX keeping only generated code. control_load is called automatically when the application starts, no explicit call is needed! Looks like in converted FWD will be never called!

Marius Gligor wrote:

which means the procedure is not drooped, instead the original body is replaced by an empty body. Any potential call of this procedure RUN control_load. is converted into ControlFlowOps.invoke("control_load");
Is this behavior OK or we should take care about other things?

control_load must not be dropped for multiple reasons. (1) The call to LoadControls is needed for COM objects converted to ComObjects (not to widgets). (2) control_load may call the procedure initialize-controls. (3) There are cases where properties are assigned in control_load.

BTW I created a small application using Application Builder having a PSTimer OCX keeping only generated code. control_load is called automatically when the application starts, no explicit call is needed! Looks like in converted FWD will be never called!

This is strange, I see run control_load statements in the legacy code. Also I've debugged the execution of the converted control_load procedure. Can you post the converted code?

Hynek Cihlar wrote:

Code review 3856b. I only have a few minor points.

ocx_conversion.rules

• The aliases for TREELIST must also include TREEVIEW aliases.
• Regarding dropping the init procedure. It would be safer to drop the procedure body, than the whole assignment where the procedure is referenced. I've encountered a case where such a drop caused removal of other useful logic.

checkParams in ComObject is never called.

I encountered several places where file history numbering was not correct, for example multiple numbers where there should be only one.

Widget.refreshWidget
The only implementation only forwards the call to repaint(). Why not to call repaint() directly?
Btw, to repaint a widget do:
eventDrawingBracket(widget, widget::repaint)

Similarly as above, for oleDrag use eventDrawingBracket. Btw. if you need the repaints to happen out of the os event loop, you may need to also call processRepaints.

A small formatting issue - conditionals with one line bodies are sometime missing curly braces.

getMoseIconLocation => getMouseIconLocation, also the method should be part of Theme interface and the image resources part of the theme packages.

GWD.mimeType
The method should be moved among other private methods. The input argument should be trimmed and lower-cased.

drawProgressBar and drawProgressBarBar
Params are incorrectly formatted.

ImageListWidget.listImages is missing comment.

ILW.resourceDelete(), global images are already removed on the client as part of widget destroy in AbstractWidget.destroy().

Are OLE-X and OLE-Y in pixels? If so, they should be ints.

OcxMouseHelper class is missing javadoc.

OleDragDrop class is missing javadoc.

OleDragDropHelper.dirty() a good candidate for a common method.

ProgressBarGuiImpl.height() is missing javadoc.

I've fixed your code review reported issues. OLE-X and OLE-Y are DECIMAL not INTEGER values.
My changes have been committed on branch 3856b rev 11344 to 11352. Please do a code review on my changes.

Marius Gligor wrote:

OLE-X and OLE-Y are DECIMAL not INTEGER values.

Please update the javadocs to include the information about the units of the OLE-X and OLE-Y attributes. I'm worried that the decimal type may be confused with character units.

My changes have been committed on branch 3856b rev 11344 to 11352. Please do a code review on my changes.

ocx_conversion.rules:
The copied aliases from TREEVIEW to TREELIST is not optimal. I'm afraid these could get out of sync in the future. Instead of copying the entries, just do <action>map3.putAll(map2)</action>.
Broken formatting for the rule <rule>type prog.expression and parent.type prog.release_object...

ComObject.java:
The history entry numbering is 006 008.

Theme.java:
Sorry, I should have mentioned this earlier. We already have a method for resolving theme resources. So instead of getUserDefinedMouseIconLocation, please use getBinaryResource.

ClassicTheme.java:
The order of params in the javadoc for method drawProgressBar is incorrect.

Vladimir Tsichevski wrote:

1. Got NPE in ImageGuiImpl#draw(), and has to add a check for null (this note is not about the ProgressBar though).

1. The cursor in the progressbar area is always a clock cursor.
2. The behavior differs significantly from that of the original OCX control:

If you take a look over ABL code you will see this statement chCtrlFrame:ProgressBar:MousePointer = 3.
The ProgressBar mouse cursor is intentionally set to 3 (ccIBeam=3) So, when the mouse cursor is over the ProgressBar widget we should see the IBame cursor otherwise we should see the default cursor. In progress_par_test3.p for example the mouse cursor is always the default cursor ccDefault=0.

1. The behavior differs significantly from that of the original OCX control:

How did you manage to use original ProgressBar OCX? In both environment local VM and AWS we cannot create tests using ProgressBar OCX due to the missing of a valid license!!
All my ProgressBar tests are created using a skeleton from Progress PSTimer OCX. After that I edited the generated ABL code and I added ABL code specific to ProgressBar.

Whenever we start to implement a new widget we always start with conversion. This is done on the server side by creating the server side widget interface, widget configuration and defining conversion rules. At this stage we create very simple uast tests just to check if conversion works properly, we don't care about functionality and UI. Even though these tests looks useless in fact are very useful to test the conversion part.

Once the conversion part is implemented we move forward to implement client side widget. Here in general we are concentrate to implement the widget visual aspect (draw) and handle events for mouse, keyboard, etc. At this stage we create more complex uast tests because we want to test the widget visual aspect and behavior.

Finally, if the widget is an OCX replacement, we write a simple uast test to check if the widget can be used as a 4gl extension.
We keep all our tests in testcases project which is reach collection of uast tests.

At this moment p2j is a conversion tool and we trust in our client ABL code. Once the code is running on OpenEdge client environment we consider that is a valid code. Since we assume that we convert only valid ABL code we don't do syntax checks. It is possible to write and convert invalid ABL code but the runtime behavior is unpredicted.

Hynek Cihlar wrote:

Marius Gligor wrote:

OLE-X and OLE-Y are DECIMAL not INTEGER values.

Please update the javadocs to include the information about the units of the OLE-X and OLE-Y attributes. I'm worried that the decimal type may be confused with character units.

My changes have been committed on branch 3856b rev 11344 to 11352. Please do a code review on my changes.

ocx_conversion.rules:
The copied aliases from TREEVIEW to TREELIST is not optimal. I'm afraid these could get out of sync in the future. Instead of copying the entries, just do <action>map3.putAll(map2)</action>.
Broken formatting for the rule <rule>type prog.expression and parent.type prog.release_object...

ComObject.java:
The history entry numbering is 006 008.

Theme.java:
Sorry, I should have mentioned this earlier. We already have a method for resolving theme resources. So instead of getUserDefinedMouseIconLocation, please use getBinaryResource.

ClassicTheme.java:
The order of params in the javadoc for method drawProgressBar is incorrect.

I've fixed reported issues. Also I've fixed some of the Vladimir reported issues.
Please do a review of changes in branch 3856b rev 11353 and 11354

Marius Gligor wrote:

Vladimir Tsichevski wrote:

1. You can install a VisualStudio 2017 community edition 30-day trial.

After 30 days we could reinstall the VM and VisualStudio 2017 again. I hope will works.

After 30 days VS will ask you to login to the Microsoft site and confirm you want continue the trial. You will be given another 30 days of trial. No need to reinstall anything!

Marius Gligor wrote:

Hynek Cihlar wrote:

Marius Gligor wrote:

OLE-X and OLE-Y are DECIMAL not INTEGER values.

Please update the javadocs to include the information about the units of the OLE-X and OLE-Y attributes. I'm worried that the decimal type may be confused with character units.

My changes have been committed on branch 3856b rev 11344 to 11352. Please do a code review on my changes.

ocx_conversion.rules:
The copied aliases from TREEVIEW to TREELIST is not optimal. I'm afraid these could get out of sync in the future. Instead of copying the entries, just do <action>map3.putAll(map2)</action>.
Broken formatting for the rule <rule>type prog.expression and parent.type prog.release_object...

ComObject.java:
The history entry numbering is 006 008.

Theme.java:
Sorry, I should have mentioned this earlier. We already have a method for resolving theme resources. So instead of getUserDefinedMouseIconLocation, please use getBinaryResource.

ClassicTheme.java:
The order of params in the javadoc for method drawProgressBar is incorrect.

I've fixed reported issues. Also I've fixed some of the Vladimir reported issues.
Please do a review of changes in branch 3856b rev 11353 and 11354

I added validations for all ProgressBar widget properties values which support only a set of predefined values.
Changes were committed in branch 3856b rev 11355 and 11356

Code review 3856b revisions 11353, 11354, 11355 and 11356. The changes look good.

Branch 3858b was dead archived.

I'm going through the progress bar implementation merged to trunk and I think we should remove any OCX references in the classes, methods, field identifiers and legacy API. Like OcxMouseConfig, OCX-MOUSE-BUTTON, OCX-MOUSE-SHIFT, OCX-MOUSE-X, OCX-MOUSE-Y, OcxMouse, OcxDragDrop, OcxDragDropConfig, OcxMouseHelper.

The OCX string in the identifiers makes the APIs misleading as there is no connection to the OCX technology. AFAIK ProgressBar widget should be a normal legacy widget.

AFAIK ProgressBar widget should be a normal legacy widget.

Yes, I agree that we want the legacy widget case to be well supported. It does need to also replace the OCX use case.

If there is no conflict in the keywords, then it is OK to remove the OCX. If there is a conflict, then we can use a different keyword and still drop the OCX prefix.

Hynek Cihlar wrote:

I'm going through the progress bar implementation merged to trunk and I think we should remove any OCX references in the classes, methods, field identifiers and legacy API. Like OcxMouseConfig, OCX-MOUSE-BUTTON, OCX-MOUSE-SHIFT, OCX-MOUSE-X, OCX-MOUSE-Y, OcxMouse, OcxDragDrop, OcxDragDropConfig, OcxMouseHelper.

The OCX string in the identifiers makes the APIs misleading as there is no connection to the OCX technology. AFAIK ProgressBar widget should be a normal legacy widget.

I support this point of view. Moreover, I think, the same is applicable to any widget we create as a replacement for OCX controls.

Our technology must correctly convert 4gl COM syntax into Java code, which does things, what the 4gl application developers initially intended to do. Period. Beyond that, everything is implementation details.
Hence, we may follow the COM/OCX technology and terminology only as long as it suits us.

Example: in contrast with OpenEdge documentation, from 4gl code only, you cannot tell the "COM method" from "COM property get/set"call. So, in our replacement code, there is no point other than historical, make any difference in support for COM methods and COM properties.