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

I am experiencing this in 2017 R3, so I think I will report a bug.

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

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 

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