Hi,
I have a ABL socket client that sends and receives data. I have an external com object (implemented via com-handles) that displays a screen for user input. When the screen is displayed the socket can still be written to, however the socket read response procedure doesn't fire which the com object is active. Once the screen is closed all the data that should have been received over the time the com screen was opened arrives in quick sucession. This data is out of date and causes the system to hang until the system has processed it all. Is there any way to stop the socket from receiving this backlog of data? I still need the socket to be open so I can write to it.
I have tried a few things:-
I have set the sensitive attribute on the socket handle to no before the com object is called and set it back to yes after it is finished, but it still seems to receive the backlog of data.
I have set the set-read-response-procedure() attribute on the socket handle to "" before the com object is called and set it back after it is finished, but it still seems to receive the backlog of data.
The data doesn't contain a timestamp so I can not discard the data if it is old.
Any ideas?
I am on 10.2B03.
Thanks,
Craig
it sounds like the com-handle screen is blocking IO - progress is single-threaded so if something blocks IO, everything in the progress session has to wait.
When the screen closes, the block is removed, and all pending events are then applied
do you have to run the screen through com-handles ? Could you not open it by os-command or the .net process ?
Your message did not reach some or all of the intended recipients.
Sent: Mon, 13 Aug 2012 09:33:53 -0400
Subject: Neue Nachricht: "Re: Issue receiving Socket data"
The following recipient(s) could not be reached:
mikefe@consultingwerk.onmicrosoft.com
Error Type: SMTP
Error Description: No mail server
Additional information: No mail servers exists for the address.
hMailServer
Hi Julian,
Thanks for the reply.
I assume all the data is getting buffered in the OS somewhere waiting for the progress process to become responsive again and .
Its an windows ActiveX dll for a credit card solution. Reading other post an activeX dll can not be used in the same way as a .Net dll? It has to be accessed via com-handles?
Craig
is it a standard credit card solution ? there are some .net solutions
out there (we use ipworks inpay) that make switching from gateway to
gateway relatively easy
all activex stuff is through com-handles - perhaps the code that
starts the activex has some issues with blocking ?
Feel free to send direct the offending code and I'll have a look
Julian pointed me in the right direction.
I created a .net dll which referenced the activeX control. I exposed all the functionality I needed. I then used the .net dll in combination with the wait-for statement to run the activeX dll on the .net vm allowing the progress vm to receive the socket data while the activeX screen was visible.
Thanks,
Craig