Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 1 to 6 of 6 total |
TServerRequest.Cancel |
Tue, May 17 2016 11:41 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent 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 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 |
This web page was last updated on Wednesday, April 17, 2024 at 10:35 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |