We value your feedback.
Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!
Course Of The Month
2 days, 1 hour left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
3 Comments
I'm not sure what you're trying to achieve. If you mean cancel all further execution of a method once a particular set of conditions are met then you could test for the condition at strategicpoints in your method...
if (conditionsMet()) return;
For a long running method that's processing a list or a collection etc then you put this inside your processing loop and you might want to use 'break' instead of 'return' to allow for finalisation processing outside the loop.
If you mean pause a method so it can pick up where it left off later then you could use a similar approach but you'll need to save the state and include logic that allows the method to pick up half way through. I guess you might pass the state in as an object that you can update. That way the calling code can take care of saving it away and making sure it passes the correct state back in.
If you want the user to have a cancel button then you're into more than one thread anyway, otherwise your UI is locked.
Hope this helps. Please post more details if you meed a more precise answer.
if (conditionsMet()) return;
For a long running method that's processing a list or a collection etc then you put this inside your processing loop and you might want to use 'break' instead of 'return' to allow for finalisation processing outside the loop.
If you mean pause a method so it can pick up where it left off later then you could use a similar approach but you'll need to save the state and include logic that allows the method to pick up half way through. I guess you might pass the state in as an object that you can update. That way the calling code can take care of saving it away and making sure it passes the correct state back in.
If you want the user to have a cancel button then you're into more than one thread anyway, otherwise your UI is locked.
Hope this helps. Please post more details if you meed a more precise answer.
I agree with RG59... as soon as you start talking about outside intervention causing the pause, you are by nature talking about threads. The "without using threads" is kind of a misnomer anyway since any time you run a program you are using at least one thread, but I assume you meant you didn't want to use thread control code. In which case, I 'd ask the question, why the avoidance?
The only real difference between what RG59 is suggesting with the boolean checks at a strategic point and what you would probably do with threading is that threading your 'flags' would be locks or wait events (such as ManualResetEvent).
Regardless of which way you implement (boolean flags or wait events), you still need to be thinking about threading because if you implement the boolean flag as a static variable or member variable, then you have to realize that if multiple threads are going through the method they will all get cancelled when you flip the flag. There are certainly techniques that can be used so that you can cancel on a per-method-running-instanc
More details aredefinitely needed to give you a more complete answer. Maybe some psuedo-code or a use case that describes what you are trying to do? And an explanation of why you want to avoid thread control code?
The only real difference between what RG59 is suggesting with the boolean checks at a strategic point and what you would probably do with threading is that threading your 'flags' would be locks or wait events (such as ManualResetEvent).
Regardless of which way you implement (boolean flags or wait events), you still need to be thinking about threading because if you implement the boolean flag as a static variable or member variable, then you have to realize that if multiple threads are going through the method they will all get cancelled when you flip the flag. There are certainly techniques that can be used so that you can cancel on a per-method-running-instanc
More details aredefinitely needed to give you a more complete answer. Maybe some psuedo-code or a use case that describes what you are trying to do? And an explanation of why you want to avoid thread control code?
Featured Post
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Introduction
Hi all and welcome to my first article on Experts Exchange.
A while ago, someone asked me if i could do some tutorials on object oriented programming.
I decided to do them on C#. Now you may ask me, why's that?
Well, one of the re…
Calculating holidays and working days is a function that is often needed yet it is not one found within the Framework. This article presents one approach to building a working-day calculator for use in .NET.
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…
Add bar graphs to Access queries using Unicode block characters. Graphs appear on every record in the color you want. Give life to numbers.
Hopes this gives you ideas on visualizing your data in new ways ~
Create a calculated field in a query:
…
Suggested Courses
Course of the Month2 days, 1 hour left to enroll
717 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.