johannc
|
|
« on: May 03, 2010, 10:24:54 PM » |
|
What is the best way cancel all requests for a remote function when the TRtcResult is possibly freed before the call returns? I have tried CancelRequests and that does not seem to solve the issue.
|
|
|
Logged
|
|
|
|
D.Tkalcec (RTC)
|
|
« Reply #1 on: May 03, 2010, 10:34:31 PM » |
|
Before destroying a TRtcResult component, close the connection used to send the remote function calls by setting AutoConnect to FALSE, calling Disconnect and looping until "isConnecting=FALSE" for the connection component in question. After that use SkipRequests, because CancelRequests will be calling "ResultAborted" events.
Best Regards, Danijel Tkalcec
|
|
|
Logged
|
|
|
|
johannc
|
|
« Reply #2 on: May 04, 2010, 02:13:06 AM » |
|
Ok thanks a lot for the solution.
|
|
|
Logged
|
|
|
|
kavetu
Newbie
Posts: 20
|
|
« Reply #3 on: May 04, 2010, 09:25:24 AM » |
|
Danijel,
>Before destroying a TRtcResult component, close the connection used to send the remote function calls by >setting AutoConnect to FALSE, calling Disconnect and looping until "isConnecting=FALSE" for the >connection component in question. After that use SkipRequests, because CancelRequests will be calling >"ResultAborted" events.
>Best Regards, >Danijel Tkalcec
Could this perhaps be packaged into a single property or procedure in the next release of RTC SDK?
Manfredt Kavetu
|
|
|
Logged
|
|
|
|
D.Tkalcec (RTC)
|
|
« Reply #4 on: May 04, 2010, 09:55:05 AM » |
|
If you want this in a procedure, here is one way of writing it:
procedure DisconnectClient(Sender:TRtcHttpClient); var oldAutoConnect:boolean; begin if Sender.isConnecting then begin oldAutoConnect:=Sender.AutoConnect; Sender.AutoConnect:=False; Sender.Disconnect; if Sender.MultiThreaded then beigin while Sender.isConnecting do Sleep(10); end else if not Sender.Blocking then begin while Sender.isConnecting do begin Application.ProcessMessages; Sleep(10); end; end; Sender.SkipRequests; Sender.AutoConnect:=oldAutoConnect; end; end;
But ... I don't like extending the RTC SDK with procedures for doing things which can already be done with a few lines of code, so I'm not really eager to adding this as a new property or a procedure to the RTC SDK. If I start doing that, I would probably end up with hundreds of small procedures for small specific tasks, most of which used only by one or two developers and a very steep learning curve for anyone who would like to start using the RTC SDK.
Best Regards, Danijel Tkalcec
|
|
|
Logged
|
|
|
|
johannc
|
|
« Reply #5 on: May 11, 2010, 02:36:54 PM » |
|
Ok, this implementation works in Windows 7 Professional (64-bit) with no issues but it still continues to plague Windows XP with a call to the freed TRtcResult. So what I have done is to implement a timer that is enabled when the CloseQuery event is fired. If there are outstanding calls, we don't close the dialog, and have the timer check this Requests until all are completed.
|
|
|
Logged
|
|
|
|
D.Tkalcec (RTC)
|
|
« Reply #6 on: May 11, 2010, 02:41:24 PM » |
|
Hi Johann,
I have to admit that I'm not a fan of forced disconnects. Even if the code I've posted above does work on newer Windows versions, I think your implementation (waiting for the response on all active requests before Quit) is a much better general solution.
Best Regards, Danijel Tkalcec
|
|
|
Logged
|
|
|
|
johannc
|
|
« Reply #7 on: May 11, 2010, 02:49:57 PM » |
|
Yes, I am more comfortable with that method. Allow all calls to complete based on condition and close when ready.
Thanks
|
|
|
Logged
|
|
|
|
D.Tkalcec (RTC)
|
|
« Reply #8 on: June 23, 2017, 12:26:27 PM » |
|
Just for the record ... "DisconnectNow" method was added to the TRtcHttpClient component in one of the later RTC SDK updates (don't remember the exact version), which can be used to close a connection and wait for all events to finish execution. After calling DisconnectNow, it is safe to destroy the connection component as well as any other components used by the connection component.
Best Regards, Danijel Tkalcec
|
|
|
Logged
|
|
|
|
|