1. Arcady Abramov
  2. Beta Testing
  3. Wednesday, 16 September 2020 04:43 AM UTC

Hello, all

Are there any enhancements in DotNetAssembly and DotNetObject classes and functions in this release?

They are not usable in R2, because of lack of support for nested .NET classes. I.e., if I have 2 .NET classes, which are fully imported into PB, I cannot import a third class, which has the above classes as it's properties.

Which makes the whole feature useless at this time.

Will it be available in R3?

Thank you

Arcady

Arcady Abramov Accepted Answer Pending Moderation
  1. Thursday, 17 September 2020 03:36 AM UTC
  2. Beta Testing
  3. # 1

Michael,

Thank you for your response.

But there is no point writing wrappers when OLEObject does the same exact thing with almost zero code.

Technology from 15 years ago does the thing and the version from a year ago does not.

Can someone please explain to me in engineering terms why this is? I am an engineer, I know that if I can read all the properties of class1, then I am supposed to be able to see class1 it when it is part of another class2. It makes ZERO sense if I do not. 

I am not asking for handling specific .NET things. This is the most basic stuff. Without it, there is no point to DotNetObject class. OLEObject from 15 years ago works better.

 

Arcady

Comment
  1. Michael Kramer
  2. Thursday, 17 September 2020 22:50 PM UTC
I like Appeon's agile approach of gradual improvements guided by user feedback. I'm sure Appeon appreciates your critique because it helps guide future versions.

You ask why native .NET interop at all when it doesn't met your "basic needs" in "release 1.0"? => Native .NET interop eliminates dependency on COM! User feedback informs PB future development.

Current interop feature was sufficient for my immediate needs so I replaced most COM-based interop. But I would love to see enhancements, just like you! Support for more complex data exchange or object access eliminates most code for marshalling/unmarshalling in both PowerScript and C#.

On the other hand, I skipped native WebBrowser in PB 2019 R2. It lacked EvaluateJavaScript. That API is new with PB 2019 R3 so I will probably make the switch when R3 releases.

HTH /Michael
  1. Helpful
  1. Armeen Mazda @Appeon
  2. Thursday, 17 September 2020 22:53 PM UTC
Hi Michael, I guess Arcady is asking why getting rid of COM is a good thing?
  1. Helpful
  1. Michael Kramer
  2. Thursday, 17 September 2020 23:24 PM UTC
Yeah, could be. As I remember from top of my head:

* COM does not have access to static methods - it is strictly object based

* COM requires parameter less constructor - PB's .NET interop already supports parameterized constructors

* Hard to use enumerated types. You have to know the numeric value of each enum value.

* COM requires extra work outside PowerScript to define the COM callable object.

* No MS plans AFAIK to improve COM - so no chance of improvements to current lacking features.

HTH /Michael
  1. Helpful
There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Thursday, 17 September 2020 00:05 AM UTC
  2. Beta Testing
  3. # 2

Hi Arcady,

You need some kind of facade or adapter in front of your .NET class when your .NET object structure is outside the supported structures of PB's native .NET interop. The exact same issues occur when you use COM Callable Wrapper as .NET Interop technology.

About 10 years ago I worked on app that called national databases exposing their interfaces via web-services. We could not connect directly from PB 11.5, nor PB 12.5 later on. We had to write facade in C#. We used COM  callable wrapper to call C# written assembly from PowerScript.

Data structures passed back and forth were very complex highly nested data structures. Arrays of structs of arrays of structs of . . . You get the picture I assume.

Now, such structure is impossible to pass directly via COM. Same if using PB native .NET interop. Here is what we did:

* Each public API of our C# facade followed this pattern:

function CreateSuperFundSite( string IN-data )
return string // OUT-data
throws exceptions

The IN-data was an XML-string encapsulating the complete input data structure. Often 5+ nested layers of arrays of structs.

The OUT-data return value was also an XML-string encapsulating similar complete data structure.

These days I would use JSON instead of XML but same design pattern: Facade to hide complexity. Typically one PB facade class taking whatever PB data structures marshall to interchange format; call .NET facade; accept return data and unmarshall from interchange format.

On the .NET side the front-end C# class simply unmarshalled the IN-data; initiated whatever processing required; marshalled result and returned it.

It works! /Michael

Comment
There are no comments made yet.
Arcady Abramov Accepted Answer Pending Moderation
  1. Wednesday, 16 September 2020 15:27 PM UTC
  2. Beta Testing
  3. # 3

Thank you, Armeen

Nested classes is not what I mean.

There is also no need to import decimals, Lists, Dictionaries, etc

I need the simplest of things.

 

Class1: 

public string prop1 {get; set;}

 

Class2: 

public string prop2 {get; set;}

public Class1 class1_prop {get; set;}

 

Class1 imports fine.

Class2 only imports prop2 and not class1_prop. There is no way to access class1_prop.

 

Which makes the whole thing useless, because there are no usable classes, who do not reference other classes as properties.

Arcady

Comment
  1. Julie Jiang @Appeon
  2. Friday, 18 September 2020 08:00 AM UTC
Hi Arcady,

You are using more than one-level dot notation for getting or setting a property and having the class as the value of a property. This is currently not supported.



As explained in https://docs.appeon.com/pb2019r2/application_techniques/ch20s01.html#d0e14922:

Getting or setting a property is supported, except for the following:

1) More than one-level dot notation for getting or setting a property. For example, the following is unsupported: Student.Informations.Name="Kit".

2) Using a generic type, delegate, or class as the value of a property.

3) Private or Protected property

4) Indexer

Best regards, Julie
  1. Helpful
  1. Arcady Abramov
  2. Friday, 18 September 2020 11:21 AM UTC
I am sorry, Julie

You are saying the Class1.prop2.prop1 does not work.

But the following code does not work either:

Class2 var2

var2 = Class1.prop2

string str1 = var2.prop1



Class1.Prop2 is unaccessible, because it is a class!

I would love to see an example where it is not so.
  1. Helpful
  1. Ricardo Jasso
  2. Friday, 18 September 2020 14:53 PM UTC
Arcady,



PB’s .NET import facility creates NVO proxies to .NET classes’ properties and functions. If the properties and function’s arguments are of simple .NET datatypes PB will use a corresponding PowerScript datatype to pass values back and forth. But it they are of complex types PB would need to access them by reference and that is not be possible because .NET classes are managed code which have their own managed memory space.



Maybe you want to use .NET classes as you would in C# or VB.NET, by means of the “Using” and “Import” declaratives, respectively. But that is quite different. That would be like using PB extension libraries. It’s not possible to incorporate .NET classes in PB and use them to create descendant classes, for example.



What I think Appeon could do is create separate NVO proxies for each complex property and if the complex property has another complex property then create a second NVO proxy for that property and so forth. The end result would be multiple proxies that could be used to pass back and forth values of simple datatypes. The trick would be how to link dependent proxies to their main proxy.



HTH,

Ricardo

  1. Helpful
There are no comments made yet.
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 16 September 2020 15:09 PM UTC
  2. Beta Testing
  3. # 4

Hi Arcady,

I think perhaps our documentation needs to do a better job of explaining this feature.  The idea behind the interop is that for complex .NET DLLs (e.g. absract classes, generic classes, and other limitations) you need to create an adapter in C# or VB.NET and your PowerScript code would interface with the adapter DLL rather than directly the DLL you want to consume.

There are significant differences between PowerScript and .NET languages, so it is not going to be feasible or at least not commercially so to remove these limitations.  In other words, this feature is never going to be able to simply import any .NET DLL without any work on your part (you will need to put the effort to create an adapter DLL).

With that said, nested classes are supported but there is limitation that you need to use the plus sign (“+”) instead of the dot (“.”) to access the nested class: [namespace].[class]+[nested-class].

By the way, here is the complete list of all new features and enhancements in PowerBuilder 2019 R3: https://docs.appeon.com/pb2019r3/whats_new/ch01.html

Best regards,
Armeen

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.