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
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
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
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