We are currently (as of last week) using 11.5.1.011 64 bit with Infragistics Version=14.2.20142.2168. Our workstations are all Windows 7 and have appservers running on Windows 2008 R2 servers.
We have a few functions using .net forms that can end up running a long (over 1 minute) appserver process to get the data requested by the user. Our main application window is also a .net form (MdiContainer).
Once you get the "Not Responding" message in the title bar you are able to click on the form and also click on the "x" to close the window. When you do this you get a set of nasty errors and end up in .net error message loop and have to use the task manager to kill the session. Is there a way to prevent this from happening? Is there a way to trap for trying to close the .net form while an appserver call is running? I've already opened a ticket with progress and was told that the only solution is to use Async appservers but not quite sure how this would work in an on-screen inquiry function. Just don't ever want to have a customer see a Progress error (other than a major network drop or server issue). Any help would be appreciated.
---------------------------
Error (Press HELP to view stack trace)
---------------------------
SERVER 172.20.2.46::DevAimbridge::3105::a1d505f3552c26f5:-63ae914a:150edc153f7:-6379 is not connected. (5451)
---------------------------
OK Help
---------------------------
---------------------------
Error (Press HELP to view stack trace)
---------------------------
Invalid or inappropriate server handle specified for RUN OERA/support/proSIinvokeMethod.p ... ON SERVER statement. (5453)
---------------------------
OK Help
---------------------------
---------------------------
Error (Press HELP to view stack trace)
---------------------------
Error attempting to push run time parameters onto the stack. (984)
---------------------------
OK Help
---------------------------
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.
************** Exception Text **************
System.ApplicationException: SERVER 172.20.2.46::DevAimbridge::3105::a1d505f3552c26f5:-63ae914a:150edc153f7:-6379 is not connected. (5451)
Invalid or inappropriate server handle specified for RUN OERA/support/proSIinvokeMethod.p ... ON SERVER statement. (5453)
at Progress.ClrBridge.BrgClrToPro.InvokeMethod(UInt64 , Int32 , String , Int32 , Object[] , Int32[] , Type[] , Object )
at Dphs.Custom.SmartComponents.DphsWindowForm.OnFormClosing(FormClosingEventArgs ) in AblProxy.cs:line 53
at System.Windows.Forms.Form.WmClose(Message& m)
at Progress.Windows.Form.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
"Not Responding" indicates that the application has stopped processing messages in its message queue. Windows thinks that the process is possibly hung and gives the user the opportunity to kill it. It does this by creating a "ghost" window which overlays the application's window. The ghost window's close button is active so that you can click it to close the application. Windows does it this way because the close button of the real window (your application's window) can't be clicked because the process isn't handling messages.
Rather than try to deal with what happens when a user clicks the close button on the ghost window you really want to avoid getting the ghost window in the first place. That's why support suggested using async.
I'm guessing that other members of the community have had to deal with long-running appserver calls and can give some advice on how to avoid this situation.
By using async AppServer calls you can keep the application responsive to events. This has multiple benefits:
- No "Not responding" message/grayed out window.
- Ability to show feedback to the user (e.g. show some sort of activity indicator like a progress bar spinning wheel).
- Ability to allow user to (try to) close the screen while the async request is still outstanding.
-> you can then still decide if this is allowed or not.
This should work fine with an "on-screen inquiry function"
Using an ASYNC call had issues in 11.0 where it would not work when using INPUT-OUTPUT datasets as shown below.
I am not sure if this has been resolved or not.
RUN ServiceInterface.p ON SERVER vhAppService ASYNCHRONOUS SET ah EVENT-PROCEDURE "CallService" IN hAsyncEventHandler (INPUT ipcEntityName,
INPUT ipcOperationName, /* operation name */
INPUT-OUTPUT DATASET pdsContext,
OUTPUT DATASET-HANDLE ophDataSet,
INPUT-OUTPUT DATASET-HANDLE hNullDataSet,
OUTPUT opcException).
I just quickly tested this in 11.4 and the exact error is:
Not legal to run request with dataset parameters asynchronously. (12769)
As a work-around: we return asynchronous datasets as two longchars - one containing the results of write-xml-schema, the other containing the results of write-json.
If you don't need the extra functionality that's added to the temp-tables in the dataset (like before table) on the receiving sides, then you can pass the individual temp-tables instead. That can be done asynchronously.
Add your vote here for asynchronous dataset passing: community.progress.com/.../add_ability_to_pass_datasets_asynchronously
@Larry, you probably need to "join" the Product Enhancement group.
You should have such an option under Member Options. Alternatively go to the ovierview tab and there you'll see a "Join" buton. Once you'll have joined you'll be able to vote.
I would also be very interested to hear how anyone has handled this problem beyond never running anything on the appserver that takes more than a moment to complete.
Making asynchronous processing work well in the middle of a work flow process that needs the decisions from step 1 in order to start step 2 can be time-consuming and risky, and it seems like there should be a way to address the actual problem of "not responding" instead of having to design and code around it.
Mark