Something to send in as a suggestion, along with where you see the priority. Quick cancellation is at times (not always, but more often than you might think) bound closely to speed. Consider the classic case, of recursion... how often do you want the work to surface from deep recursion to check if a cancellation is required? Do it often enough for quick cancellation and you eliminate the speed benefit of the technique. There are also costs to cancellation in cases where large temp files are constructed. You can see an analogous situation when cancelling big copies in Windows: it takes the system time to delete what has been created to clean up once a cancel has been commanded. If gigabytes are involved, it could take more time to cancel than to continue to the finish. It's like flying from London to New York and then commanding a "cancel" of the flight when on final approach to the destination airport... turn around and fly back to London? It sounds like with queries you are encountering the first effect more than the second. No doubt there is room for improvement. But at what priority over other things? Given a mention in the forum is opening the door to opinions, I'd rank it as one of those "nice to do on an ongoing basis" things that, in specific cases where many people want effort would rank a higher priority, but otherwise not something to take significant time away from, say, interactive editing, filling GUI holes, raster editing and similar. By the way, taking a totally primitive approach to this... I always make backup copies and then if I want to stop doing something I have the option of using Task Manager to do a "super cancel." :-) Brutal, perhaps, but effective when I have no patience.
|