Increase expert visibility of your issues by participating in Priority Question, our latest feature for Premium and Team Account holders. Adjust the priority of your question to get emergent issues in front of subject-matter experts for help when you need it most.
COURSE of the MONTH
14 days, 14 hours 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
This article series is supposed to shed some light on the use of IDisposable and objects that inherit from it. In essence, a more apt title for this article would be: using (IDisposable) {}. I’m just not sure how many people would ge…
It was really hard time for me to get the understanding of Delegates in C#. I went through many websites and articles but I found them very clumsy. After going through those sites, I noted down the points in a easy way so here I am sharing that unde…
Michael from AdRem Software outlines event notifications and Automatic Corrective Actions in network monitoring. Automatic Corrective Actions are scripts, which can automatically run upon discovery of a certain undesirable condition in your network.…
Have you created a query with information for a calendar? ... and then, abra-cadabra, the calendar is done?! I am going to show you how to make that happen.
Visualize your data! ... really see it
To use the code to create a calendar from a q…
Suggested Courses
Course of the Month14 days, 14 hours left to enroll
770 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.