Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 6 of 6 total
Thread TServerRequest.Cancel
Tue, May 17 2016 11:41 AMPermanent Link

Matthew Jones

When TServerRequest.Cancel is called, I think it should no longer do
the OnComplete functionality. That said, I'm not sure what is actually
happening in my situation, but let me explain.

I have a TServerRequestQueue on a form, and a sub-form that does a
lookup. The lookup is done by asking the TServerRequestQueue for a
Request with GetNewRequest to fill in and it then uses AddRequest to
make it live. However, sometimes it takes a long time, and the user
closes the form (well, I do!). As part of the Close, I call
       m_xRequest.Cancel;

What is happening is that the request is coming back, but a label that
usually is able to have the status is now null because it has been
free'd I presume, and thus it fails. The call stack starts at
ReadyStateChangeHandler which I don't quite understand, but I guess
that is where it needs to know it was cancelled and shouldn't call
complete.

It also looks like the callback is called on the normal Cancel call,
which I think should not happen either, or if it does, the passed in
Request should have a Cancelled property so the event handler could
tell it was cancelled. Indeed, that would fix the whole thing - add a
Cancelled property, set it false on AddRequest (starting the request),
and set it true if cancel is called on it. And preferably don't call
Completed if true, but at least it would allow the event to test this
and know it was cancelled.

--

Matthew Jones
Tue, May 17 2016 12:18 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Matthew,

<< What is happening is that the request is coming back, but a label that usually is able to have the status is now null because it has been free'd I presume, and thus it fails. The call stack starts at ReadyStateChangeHandler which I don't quite understand, but I guess that is where it needs to know it was cancelled and shouldn't call
complete. >>

"Complete" means "done", it doesn't mean "successful".  Check the StatusCode property of the request to see whether the request was successful or not:

http://www.elevatesoft.com/manual?action=viewprop&id=ewb2&comp=TServerRequest&prop=StatusCode

Tim Young
Elevate Software
www.elevatesoft.com
Tue, May 17 2016 12:57 PMPermanent Link

Matthew Jones


> "Complete" means "done", it doesn't mean "successful".  Check the
> StatusCode property of the request to see whether the request was successful or not:
>
> http://www.elevatesoft.com/manual?action=viewprop&id=ewb2&comp=TServerRequest&prop=StatusCode
>

But the form that the event came from doesn't exist any more. The request
may have worked fine, just slowly, but it was cancelled when the user
closed the form. Boom if it tries to do anything like assign the statuscode
to a label. (The read is okay, the label is now null)


--
Matthew Jones
Tue, May 17 2016 1:13 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Matthew,

<< But the form that the event came from doesn't exist any more. >>

That's a coding issue, not a TServerRequest issue.  I can't tell exactly how you have your code set up, by the description, but you shouldn't hook event handlers up to class instances that could disappear during the lifetime of the event's parent class instance that is triggering the event.

Tim Young
Elevate Software
www.elevatesoft.com
Wed, May 18 2016 4:27 AMPermanent Link

Matthew Jones

Tim Young [Elevate Software] wrote:

> << But the form that the event came from doesn't exist any more. >>
>
> That's a coding issue, not a TServerRequest issue.  I can't tell
> exactly how you have your code set up, by the description, but you
> shouldn't hook event handlers up to class instances that could
> disappear during the lifetime of the event's parent class instance
> that is triggering the event.

Indeed, which is sort of why I'd like to be able to cancel the event
from happening at some arbitrary point in the future outside of my
control. Even if the event handler was on my main form, and it checked
if a child form was present to handle it, it might not be the same form
that put in the request minutes earlier.

However, I shall use the Tag of the request to indicate it was
cancelled, so I can ignore the event happening, and that will do. A
proper Cancelled property and no further event would be nicer.

--

Matthew Jones
Wed, May 18 2016 11:31 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Matthew,

<< Indeed, which is sort of why I'd like to be able to cancel the event from happening at some arbitrary point in the future outside of my control. Even if the event handler was on my main form, and it checked if a child form was present to handle it, it might not be the same form that put in the request minutes earlier. >>

Yes, and that's *still* a coding issue, not a design issue with the way that the TServerRequest events work.  *Every* event in EWB has the potential for the above scenario.

Tim Young
Elevate Software
www.elevatesoft.com
Image