Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (4)

Resolved PB 2019 OLEObject not working?

  1. Issue
0
Votes
Undo
  1. John Raghanti
    John Raghanti
  2. PowerBuilder
  3. Friday, 9 August 2019 17:29 PM UTC

Hello. We are migrating a client/server desktop application from PB 12.5 to PB 19. Some of our OLEObject functionality appears to have broken, and I'm looking for some help. It's a homegrown DLL wrapper to C#.

Here is a snippet of the code in question:

oleobject inv_ole
inv_ole = CREATE OLEObject
result = inv_ole.ConnectToNewObject("Our.HomeGrown.PBWrapper.DoIt")
if result <> 0 then
     DESTROY inv_ole
     SetNull(inv_ole)
     return
end if

inv_ole.MessageWindowHandle = handle(this)

 

In PB 12.5, everything works as expected. In PB 19, I get the following error:

(Error: 39) Error accessing external object property messagewindowhandle at line 113 in ue_ourevent event of object w_our_window line 113 in ue_ourevent event of w_our_window

 

Any thoughts? Thanks!

  1. OLE
Migration of application PowerBuilder 2017 from Wi...
Paramaterized Constructor Event for PowerBuilder S...
Responses (4)
Armeen Mazda @Appeon
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Friday, 9 August 2019 19:57 PM UTC
  2. PowerBuilder
  3. # 1

I know this won't help you immediately, but in Revision 2 of PB 2019 we are adding ability to directly call C# assemblies without having to create wrappers/workarounds.  At this time, the best estimate I can give you is that Revision 2 will be released early November.

Comment
Yiannis Papadomichelakis
  1. Yiannis Papadomichelakis
  2. Friday, 6 December 2019 18:27 PM UTC
This is very interesting!

Will we be able to handle c# events using this method?
  1. Helpful
Govinda Lopez @Appeon
  1. Govinda Lopez @Appeon
  2. Friday, 6 December 2019 19:34 PM UTC
Hi Yiannis,



The C# Class Importer can import the names and data types of the C# classes, functions, properties and parameters from the C# assembly to the application PBL. It creates the CSharpObject object as an NVO for each C# class and then imports the C# functions to the NVO. After that you can write scripts to call the NVO and functions directly to execute the corresponding C# code. It can also create the CSharpAssembly object for each CSharpObject object and add try-catch and handle the errors, which can greatly simplify the scripts that you might need to write.



So, in other words, importing C# dll's doesn't automatically map your C# events to PowerScript events. You can call the imported functions as needed though.



I hope this helps answer your question.





Regards,
  1. Helpful
There are no comments made yet.
Tobias Roth
Tobias Roth Accepted Answer Pending Moderation
  1. Friday, 9 August 2019 20:38 PM UTC
  2. PowerBuilder
  3. # 2

Hi Armeen, 

I have two questions about the ability to directly call c# assamblies in R2.

Do we need to register the c# assamblies? 

How good are the chances for the estimated release date "early november"?

We would need some more technical information about that feature.

Thanks & Regards Tobi

Comment
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Friday, 6 December 2019 18:33 PM UTC
Hi Tobias, We have decided to add more features to R2 so we will do a customer beta in January 2020 and tentative release date for final version in March 31, 2020. You can try the beta in January and I think that'll be the best way to understand how well it fits your project needs.
  1. Helpful
There are no comments made yet.
Armeen Mazda @Appeon
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Monday, 12 August 2019 19:52 PM UTC
  2. PowerBuilder
  3. # 3

Hi Tobias,

No, you do not need to register the C# assemblies. It's very easy to deploy!

There is very good chance about the estimated release date since our engineers have working example already, but please check back around end of September to get status update.

Here is a code example of how to call C# assemblies using our internal test version of PB 2019 R2:

lcsa_assem = create CSharpAssembly
lcsa_object  = create CSharpObject

ll_return  = lcsa_assem.loadwithnetframework("NetAssemTest.dll", false)
mle_1.text += "lcsa_assem.loadwithnetframework:"+ string(ll_return) + "error:"+string(lcsa_assem.errortext)+"~r~n"

ll_return = lcsa_assem.createinstance("assemblynet.CSharpClass",lcso_object)
mle_1.text += "createinstance:"+ string(ll_return) +"~r~n"

li_c = 1
li_c = lcso_object.GetSalary()
mle_1.text += "GetSalary return =10000:"+ string(li_c)+"~r~n"

Regards,
Armeen

Comment
Load more comments
Ferdinand Fischer
  1. Ferdinand Fischer
  2. Wednesday, 14 August 2019 16:48 PM UTC
Hi Mark,



thank you very much for your answer.



Will there be webinar in the future, that shows the full functionality?



Regards,

Ferdinand







  1. Helpful
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Wednesday, 14 August 2019 17:48 PM UTC
Most likely there would be, but at this point we haven't scheduled yet so please stay tuned. If you are not yet subscribed to Appeon newsletter, we suggest you subscribe so you get notified: http://eepurl.com/bGcjSD
  1. Helpful
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Friday, 6 December 2019 18:34 PM UTC
Here is video showing this feature: https://youtu.be/kmzvjQ6yI-Y?t=305
  1. Helpful
There are no comments made yet.
John Raghanti
John Raghanti Accepted Answer Pending Moderation
  1. Wednesday, 14 August 2019 14:02 PM UTC
  2. PowerBuilder
  3. # 4

I found a way around the issue. In talking with Appeon, they mentioned ANSI encoding vs. UTF-16LE. That got me looking at the variables on both sides of the equation, C# and PB. While there was no noticeable difference, I did notice that the instantiated inv_ole object looked slightly different between PB 12.5 and PB 2019 at runtime.

On a guess, I decided to strongly type the variable being used to set the handle.

I changed this code:

            inv_ole.MessageWindowHandle = handle(this)

To this:

            Long ll_handle
            ll_handle = handle(this)
            inv_ole.MessageWindowHandle = ll_handle

Everything works as expected now. I'm guessing the the OLE Object couldn't resolve the variable type being used?

 

Comment
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Friday, 6 December 2019 18:35 PM UTC
Thanks for sharing the solution!
  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.