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

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

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

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