OE 11.5.1 I am looking at OpenEdge.Net.ServerConnection.ClientSocket:WaitForResponse ( i as integer ) and for the life of me, I can't figure out what this is for: wait-for 'U2':u of mhSocket. Have you been running your tests in non-event driven sessions? Code which worked in 11.5 now spews:
[15/06/11@16:39:42.281-0400] P-001784 T-001556 1 4GL SOCKET CONNECT: TIME=46
[15/06/11@16:39:42.284-0400] P-001784 T-001556 1 4GL SOCKET WRITE: TIME=0; SIZE=33006
[15/06/11@16:39:42.295-0400] P-001784 T-001556 1 4GL -- Encountered an input-blocking statement while executing a user-defined function or non-void method: 'Execute' that is invalid within the current runtime context. (2780)
[15/06/11@16:39:42.295-0400] P-001784 T-001556 1 4GL -- ** ABL Debug-Alert Stack Trace **
[15/06/11@16:39:42.295-0400] P-001784 T-001556 1 4GL -- --> WaitForResponse OpenEdge.Net.ServerConnection.ClientSocket at line 298 (OpenEdge/Net/ServerConnection/ClientSocket.r)
[15/06/11@16:39:42.295-0400] P-001784 T-001556 1 4GL -- Execute OpenEdge.Net.HTTP.Lib.ABLSockets.ABLSocketLibrary at line 186 (OpenEdge/Net/HTTP/Lib/ABLSockets/ABLSocketLibrary.r)
[15/06/11@16:39:42.295-0400] P-001784 T-001556 1 4GL -- Execute OpenEdge.Net.HTTP.HttpClient at line 139 (OpenEdge/Net/HTTP/HttpClient.r)
[15/06/11@16:39:42.295-0400] P-001784 T-001556 1 4GL -- Execute OpenEdge.Net.HTTP.HttpClient at line 94 (OpenEdge/Net/HTTP/HttpClient.r)
Are we no longer supposed to execute execute?
Error 2780 occurs most likely because you do not start with the " -IOEverywhere 1" startup parameter.
Add that and the problem should go away.
Good thought, but not so. -IOEverywhere 1 is the default in version 11. Without this, (IOEverywhere 0) you cannot use any IO-blocking statement in a function or non-void method. It can't be the 1st one, or a stacked one. Doesn't matter if it is for a modal window (dialog box) or a non-modal one.
With -IOEverywhere 1, most of these restrictions have gone away, but one remains. This is if you are trying to use a stacked IO-blocking statement for a non-model window, over an existing .NET-style WAIT-FOR and you are in a function or non-void method. Apparently that is the case here.
Wow! Laura hits the nail on the head from almost 1100 miles away.
My standard GUI client expects a .Net form (if none is provided, it installs itself into the system tray -- which is the current case) and runs a corresponding .Net style wait-for. In the past 10 or so years, serving as the core of several dozen applications, this is the first time there has ever been a problem with it.