1. Stephan Daschek
  2. PowerBuilder
  3. Wednesday, 2 October 2019 11:15 AM UTC

Hello,

for 2 of our Products we use PowerBuilder 12.6 .NET to call content of e.g. the System.Drawing.Printing assemblies.

PowerBuilder 12.6 .NET isn't very comfortable, contains a lot of bugs, is extremely slow & is no longer supported.

Is there any easy way to use and call those non visual assemblies e.g. with PowerBuilder 2019 and SnapDevelop (C# IDE)?

Who is viewing this page
Stephan Daschek Accepted Answer Pending Moderation
  1. Monday, 7 October 2019 08:24 AM UTC
  2. PowerBuilder
  3. # 1

First of all, thank you for your answers.

I proceeded as follows:
1. I downloaded a c# interop form toolkit and wrote a simple dll called nettest.dll.
2. I registered this dll with regasm "nettest.dll" /codebase.
3. I generated an OleObject (new -> standard class) and named it n_oleobject_test

Sourcecode (PowerBuilder):
n_oleobject_test lnv_test
lnv_test = create n_oleobject_test
lnv_test.Connecttonewobject("NetTest.NetTest")
Messagebox("your default printer is?",String(lnv_test.of_getPrinter() ))
lnv_test.Disconnectobject( )
Destroy lnv_test

Sourcecode (visual studio):
public String of_getPrinter()
{
//get default printername
PrinterSettings ps = new PrinterSettings();
return ps.PrinterName ;
}

This works fine, but is this the right way at this time until PowerBuilder 2019 R2 will be released?

Comment
  1. Michael Kramer
  2. Monday, 7 October 2019 09:20 AM UTC
Yes, it is.

The "problem" is that OLEObject has late binding (runtime resolution) of each and every call. So

1) OLEObject is potentially slow. What compiler could have done is delayed and repeated at runtime.

2) No compiler checks for the API due to the late binding. So compiler pretty much just checks the number of start and end parentheses.

3) Most often, OLEObject also requires COM registration in local Windows Registry.

4) Naming standard in PowerBuilder differs from C#. I have yet to see a C# naming rule suggesting non-visual classes prefixed [n_] and functions prefixed [of_]. So someone either writes a PowerBuilder specific adapter on top of other C# classes - or your PowerBuilder app creates an adapter NVO to encapsulate the naming differences.



I prefer validation and binding appear at compile time - and I prefer having any adapter code be auto-generated into proxy classes instead of developers writing such code manually.

/Michael
  1. Helpful
There are no comments made yet.
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 2 October 2019 16:15 PM UTC
  2. PowerBuilder
  3. # 2

Adding to what Michael said, the .NET interop feature being natively added to PowerBuilder in 2019 R2 will allow you to interop with non-visual C# assemblies. 

If it is coded in other .NET languages (e.g. VB.NET) or if it is a visual object, then the interop feature would not apply and you would need to use the COM callable wrapper workaround.

Comment
  1. Michael Kramer
  2. Wednesday, 2 October 2019 22:11 PM UTC
So it is mapping of the simple data types and how arrays + strings are defined, right?

In that case it may be possible to interop with relevant subset of assemblies written in C++, F#, and Eiffel (THAT would be awesome in and of itself due to PB's ancestry).

I would expect no-can-do for IronPython and similar depending on the dynamic language runtime.
  1. Helpful
  1. Armeen Mazda @Appeon
  2. Wednesday, 2 October 2019 23:10 PM UTC
I'm not sure about the technical details, but for sure our engineers have confirmed that only .NET assemblies written in C# are supported. Whether there is a way to hack it I don't know, but even if it can that is not advisable because it is not covered by our support.
  1. Helpful
  1. Michael Kramer
  2. Monday, 7 October 2019 11:23 AM UTC
Engineering saying C# only, I would also vote against non-C#.

THX ? MicK
  1. Helpful
There are no comments made yet.
mike S Accepted Answer Pending Moderation
  1. Wednesday, 2 October 2019 13:25 PM UTC
  2. PowerBuilder
  3. # 3

As Michael stated, it is on the roadmap, and you will most likely see it at elevate this month. While you are at elevate, you will be able to ask appeon staff directly whether your use case will work with what they are doing:

 

https://www.appeon.com/developers/roadmap

"Call C# assemblies from PowerScript apps;"

Comment
There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Wednesday, 2 October 2019 12:51 PM UTC
  2. PowerBuilder
  3. # 4

Hi Stephan,

Interop PowerScript => .NET requires COM Callable wrapper through OLEObject or other kind of interop.

Coming soon is .NET interop where PB IDE generates proxy objects. No OLEObject, no COM callable wrapper. I expect demos at Elevate conference which is late October.

Simplicity of PowerScript as we know it. Assembly loaded and .NET object instantiated behind the scenes.

HTH /Michael

Comment
  1. Miguel Leeuwe
  2. Monday, 7 October 2019 10:59 AM UTC
If I'm not mistaken all the new stuff will only be applicable to NON-Visual .Net. Not sure if Stephan needs Visual functionality with the System.Drawing.Printing assemblies?
  1. Helpful
  1. Miguel Leeuwe
  2. Monday, 7 October 2019 11:00 AM UTC
Oh, ups, Armeen already mentioned that too :)
  1. Helpful
  1. Michael Kramer
  2. Monday, 7 October 2019 11:33 AM UTC
Agree, don't code what is already a system API. But the technology is right.



My preferred example of not-already-present-but-often-relevant is a temperature conversion NVO to mix and match scales like Celsius, Fahrenheit, Kelvin, and possibly more scales.
  1. Helpful
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.