1. Yakov Werde
  2. PowerBuilder
  3. Friday, 21 July 2017 14:27 PM UTC

Our 32 bit application relies on a 3rd party 32 bit DLL COMM Port driver (via external function calls) to communicate with various scientific instruments.  The code pattern is a DO Loop making function calls and waiting. This code is embedded into device specific user object functions. (Not OO code)  Our code is tightly coupled to this driver API

Our application code is fully ported and tested  in 64 bit with the exception of this feature set.  The hold up is that the COMM driver vendor is out of business.,  There will never be a 64 bit version.

We looked at OCX solutions.  All of them supply event handlers that an app codes to respond to input buffer or signal line changes. Here are a couple of examples



The bigger challange is what to do for 64 bit.  The PB IDE only supports Event coding for 32 bit OCX controls!  For 64 bit the OCX must be dynamically loaded.  There is no place to write an event handler for a generic OLEControl!

Do you have any concrete suggestions on how to proceed?  Know of a control that might might?

Thanks for sharing

Shenn Sellers Accepted Answer Pending Moderation
  1. Monday, 24 July 2017 15:35 PM UTC
  2. PowerBuilder
  3. # 1

We use Serial Port ActiveX Control which comes with 32 bit and 64 bit versions.  It has been working great for us.


  1. yakov werde
  2. Monday, 24 July 2017 17:08 PM UTC
thanks for the suggestion.  Alas, like all of the fine members of its ActiveX breed, it offers "the complete range of events to control them"  This approach is not currently usable in a 64 bit PB application where the control has to be dynamically associated with its OLEObject reference.  Events are not exposed for coding.

  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Friday, 21 July 2017 15:01 PM UTC
  2. PowerBuilder
  3. # 2
Hi Yakov; How about leaving the COMM interaction in a separate 32bit EXE & then call that EXE from your 64bit PB App(s) using for example a command line, shared memory or a control file to pass the various instructions into the 32bit app? The control file might be the better way to go as you can then return COMM data that way as well to the main PB App. That at least would give you a workaround for now. The key for the future though sounds like you'll need to upgrade your devices to a more modern 64 bit based technology. Good luck! Regards ... Chris
  1. yakov werde
  2. Monday, 24 July 2017 13:48 PM UTC
Using Run there is no easy method for return communication. Can't can't capture a Return code from the EXE. So the main app is stuck polling.  I'm thinking about rolling the effected code back to PB 11.5 and deploying the code as a COM server.  Then we can have 2 way communication.... See any downside to this approach?  (Wishing the COM target was still around....)

  1. Helpful
  1. Roland Smith
  2. Monday, 24 July 2017 13:51 PM UTC
My RunAndWait example allows you to capture the return code from an external exe.

  1. Helpful
  1. yakov werde
  2. Monday, 24 July 2017 14:56 PM UTC
Thanks Roland,

I see handles in the Local External Function declarations .  Looks like the code will need some sprucing up to make it 12.6 64 bit compatible.

  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.