Trapping for Close of a .net form while a synchronous appser

Posted by Larry Reed on 17-Nov-2015 14:51

We are currently (as of last week) using 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 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 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)

All Replies

Posted by Matt Gilarde on 17-Nov-2015 15:04

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

Posted by Lieven De Foor on 18-Nov-2015 04:56

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"

Posted by Roger Blanchard on 18-Nov-2015 06:26

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

Posted by Roger Blanchard on 18-Nov-2015 06:56

I just quickly tested this in 11.4 and the exact error is:

Not legal to run request with dataset parameters asynchronously. (12769)

Posted by Roger Blanchard on 18-Nov-2015 07:05
Posted by Stefan Drissen on 18-Nov-2015 14:58

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.

Posted by Larry Reed on 18-Nov-2015 16:44

We've tried this as well but are still getting an error.  We have our Appserver agents using ISO8859-1 and our client is using 1252 for codepage (cpstream, cpinternal and cpterm).   Not sure if something is going astray with this configuration.  The specific character we are tripping over at this time is chr(146).

Posted by Lieven De Foor on 19-Nov-2015 03:39

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:

Posted by Larry Reed on 19-Nov-2015 15:46

What do you mean by "add your vote". I went to the link but there is no "Vote" that I can find.  We would all like to vote to have support for datasets added to async appservers. 

Posted by Jean Richert on 19-Nov-2015 16:24

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

Posted by Larry Reed on 19-Nov-2015 16:31

Thanks for the response and the explanation of the ghost window.  I'm hoping someone else in the community that hast figured something out.  I would prefer to be able to deal with what happens when a user clicks on the x when a synchronous appserver session is running.
It's a bit of work and redesign to switch to async appservers. And without support for dataset we're running into issues putting the dataset into a longchar with a codepage conversions combination of 1252 on the client and ISO8859-1 on the agents/database.   One bad character in the database is causing the process to blow up.  This is from an open ticket I have with Progress Tech Support.  I don't particularly care if the character doesn't display properly but I do care if the process blows up.  The recommendation is to clean up the bad characters and convert to utf-8.  Quite an undertaking with 600 + databases (190 or so transaction db's).  And an existing application (based on Xponent) that would need to be re-certified with the new code page.  Not something I had planned on doing.
We are 2.25 years into developing a new application using .net for GUI.  And have yet to deploy anything.  We are currently using progress 64bit which I believe is close to the latest.  And would like to be able to deal with what happens when a user clicks on the x when a synchronous appserver process is running.
Any help from Anyone would be appreciated. 

Posted by mopfer on 19-Nov-2015 16:53

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.


This thread is closed