1. Jason Schultz
  2. PowerBuilder
  3. Monday, 2 April 2018 15:13 PM UTC

Hi.  We're currently experiencing an issue with a 64-bit .exe created with PB 12.6 Classic (build 4098) running on workstations with Win 10 Fall Creators Update (Build 1709).

The application runs fine on previous versions of Win 7 and 10, and I'm told that it works on a more recent build of Win 10 as well.

Is anyone aware of any known issues between the use of OpenWithParm (passing either a PowerObject or a String) to a response window when running on Win 10 Build 1709? When the code executes, program logic continues immediately and falls through, not allowing for the response window to do a CloseWithReturn (passing back the StringParm or PowerObjectParm).  

Aside from troubleshooting with our Production application , I also created a simple application consisting of an application object and a response window.  OpenWithParm() doesn't perform as expected on Win 10 1709, but it does on a prior build of Win 10 (Build 1607). Looking for a potential workaround or justification that there is a legitimate compatibility issue with this build.  Upgrading to the latest version of PB is not a feasible option right now (perhaps later in the year). Any feedback or insight is appreciated.

Thank You,
Jason Schultz 

Michael Kramer Accepted Answer Pending Moderation
  1. Monday, 2 April 2018 15:29 PM UTC
  2. PowerBuilder
  3. # 1

Hi Jason,

I haven't noticed that issue myself but then again I don't have access to PB 12.6.

PB 12.6 on Windows 10 is a hard nut regarding support as I understand. SAP is the vendor and therefore the "go-to guy" for bug fixes. And as I recall, SAP does not support PB 12.6 running on Windows 10. SAP may however have an EBF that actually fixes your issue.

Do you see identical (wrong) behavior running PB as 32-bit and as 64-bit?
It may be that you can find some kind of combination that actually works in your specific setup without migrating to newer PB version.

 

HTH /Michael

Comment
  1. Michael Kramer
  2. Monday, 2 April 2018 18:48 PM UTC
Hi Jason, Sorry to hear no luck so far.



I was wondering whether this will do the trick. Two options depending on how the your application is designed:





Login window appearing before any other window in the app. Code continues to open additional window after login succeeds.

MDI frame visible, opens the Login response window and waits for logon before proceeding.





I used the lockdown/unlock described below in a situation where one MDI sheet behaved like a response window towards one other sheet, whereas it was just a sibling sheet to all other sheets and the frame.



My suggested approach:





Make login window a Main window.

Split the scripts opening the login window into two scripts



PRE-script: Everything from script start up to and including Open(w_login)

POST-script: Everything after Login response window returns (i.e. after the Open-call)









Option 1: Login window before all other windows





Replace the original "login" script with the PRE-script.

In case of successful login: Close login window and call POST-script

I know code can be more complicated when the login opens from a script called within a chain of other scripts - but the principle is the same - just more refactoring work.





Option 2: MDI frame visible and "locked" by Login





Basically the same rewrite as Option 1 - BUT extended as follows

Create 2 new functions on MDI frame: wf_Lockdown( ) and wf_Unlock( )

wf_Lockdown( ): Disables the window and all its controls.



Basically, the window becomes a non-reactive ghost though remains visible on screen.

NOTE: You can still call all the functions you want on the window and its controls, but all its event processing has been ghosted. So it is "modal-like". Therefor don't call Retrieve( ) or Update( ) on a DW control, that you have locked down.





wf_Unlock( ): Enables everything that wf_Lockdown disabled

When login opens: Call wf_Lockdown( ). as soon as login window has opened.

When login closes: Call wf_Unlock PRIOR to closing!

IF you must trigger events on the frame as part of your login process before login window closes: Surround such event triggering with wf_Unlock( ); trigger events; wf_Lockdown( ) to remain locked unless you explicitly state otherwise.





HTH /Michael

  1. Helpful
  1. Jason Schultz
  2. Tuesday, 3 April 2018 18:45 PM UTC
Michael,



Thanks again for the suggestions.  I'll give Option 1 a try.  My fear is that the odd behavior is occurring on any OpenWithParm and response window across the application (not just the login window) on this Win 10 build 1709.  But, we'll tackle the login window first.  Our applications are PFC apps written in the early 2000 timeframe. Out of curiosity, I downloaded a trial version of PB 2017 R2, migrated the apps and they run fine (as far as I can tell) on the Win 10 Build 1709.  Unfortunately, upgrading is not an option right now for the client.  I'll let you know how it reacts after refactoring.



Thanks Again,



Jason 

  1. Helpful
  1. Jason Schultz
  2. Thursday, 17 May 2018 14:36 PM UTC
Hi Michael,



Just wanted to provide an update on this issue.  We never did resolve the OpenWithParm() issue occurring on a 64-bit .exe generated within PB12.6 Classic and how it doesn't behave as expected when run on Win10 build 1709.  FYI, the same .exe works fine on Win 10 builds 1607, 1703 and 1803...  Just plain weird...  After noticing that PB2017R2 solved the issue (64-bit exe generated with migrated code worked fine with Win10 1709), we opted to go that direction.  Thank you again for all your help.  



Jason

  1. Helpful
There are no comments made yet.
J-Craig Maxie Accepted Answer Pending Moderation
  1. Monday, 14 May 2018 20:32 PM UTC
  2. PowerBuilder
  3. # 2

We are currently running PB SAP version 12.6 and Oracle 12.2.0.1.0; I create both 32 and 64-bit version of our software.  With Windows Update 1709 the 32-bit still works properly but the 64-bit version stopped working... no error messages, just a quick flash up on the screen then nuttin'.  A new build under the 1709 update didn't resolve anything.

However, we also have Appeon PB 2017 R2 and although I haven't officially ported our code over to it, I did try a build with Appeon and it worked properly!

I would be extremely reluctant to start changing program code to resolve an issue like this; luckily the Appeon PB solved the problem.  BTW, the code had several instances where OpenWithParm was used.  Again, no code changes, just ported application to Appeon.

Cheers, Craig

 

Comment
  1. Jason Schultz
  2. Thursday, 17 May 2018 14:28 PM UTC
Hi Craig,



Thanks for the info.  Yes, we found it easier to start migrating to PB2017R2 instead of attempting to refactor any code.  Upgrading was inevitable anyway to be Win 10 compliant.  Just very odd because the same code (64-bit .exe) works fine in Win 10 builds 1607, 1703 and 1803.  Just not 1709.   Specifically, OpenWithParm() wasn't behaving as it should (not allowing a response window to close and do a returnwithparm before program flow continues).  After downloading a 30-day trial of PB2017R2 and doing a proof of concept migration, we did find that it worked, prompting our client to go that direction sooner than expected.



Thanks,

Jason

  1. Helpful
  1. Tom Peters
  2. Tuesday, 28 August 2018 16:52 PM UTC
I am experiencing this in 2017 R3, so I think I will report a bug.
  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.