Results 1 to 20 of 20

Thread: DoEvents/Timer clarification requested.

  1. #1

    Thread Starter
    Member
    Join Date
    Jun 2018
    Posts
    34

    DoEvents/Timer clarification requested.

    The following is an excerpt from the VB6 help file for the DoEvents-Function: "DoEvents is most useful for simple things like allowing a user to cancel a process after it has started, for example a search for a file. For long-running processes, yielding the processor is better accomplished by using a Timer, or delegating the task to an ActiveX EXE component"

    The above excerpt appears to equate a Timer-Control event with an ActiveX? The implication being the within a Timer-Event, processes executed there will function virtually as independent threads. My personal observation has been that if code is being executed within a Timer-Event (or any event for the matter) no other events can be processed IF a DoEvents is not incorporated strategically within the "long-running process".

    Have I missed something in my interpretation of the excerpt above?

    Thanks, Mickey

  2. #2
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,532

    Re: DoEvents/Timer clarification requested.

    The key is "ActiveX EXE" ... emphasis on the EXE... which runs out of process. Not to be confused with an ActiveX OCX, which runs in-process. The difference is that an AxEXE can be spun up and will run in it's own thread, which then leaves the original thread unencumbered to do it's own thing. Meanwhile, because it's an ActiveX object, it can be referenced, instanciated and communicated with just like any other COM object you would use.

    timers on the other hand... that's the first time I've heard of timers being used to get around long-running blocking processes. But I believe the principle is the same... the timer actually runs on a secondary thread... I think I'm right about this... someone correct me if I'm not, but this is the way I understand it ... so it's still free to be able to raise the Tick event when it comes around. I don't have VB (heck, I don't even have VS or .NET installed any more!) but if you were to create a new app, add a button and a timer, set the timer with a duration of 500, and in the tick event, have it display a messagebox with something. In the click event of the button, start the timer, then have it start a loop where it just outputs to the debug window, and just keeps looping (this creates a busy loop, just to keep things busy) ... when you run it and click the button, it should start outputting to the debug window, and then a messagebox should pop up, and another, and another and another, and so on ad nauseum until you stop the program.

    It shouldn't even stop long enough for you to click the messagebox button to dismiss it. Like the Energizer Bunny, it should just keep going and going and going and going....


    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  3. #3

    Thread Starter
    Member
    Join Date
    Jun 2018
    Posts
    34

    Re: DoEvents/Timer clarification requested.

    Quote Originally Posted by techgnome View Post
    The key is "ActiveX EXE" ... emphasis on the EXE... which runs out of process. Not to be confused with an ActiveX OCX, which runs in-process. The difference is that an AxEXE can be spun up and will run in it's own thread, which then leaves the original thread unencumbered to do it's own thing. Meanwhile, because it's an ActiveX object, it can be referenced, instanciated and communicated with just like any other COM object you would use.

    timers on the other hand... that's the first time I've heard of timers being used to get around long-running blocking processes. But I believe the principle is the same... the timer actually runs on a secondary thread... I think I'm right about this... someone correct me if I'm not, but this is the way I understand it ... so it's still free to be able to raise the Tick event when it comes around. I don't have VB (heck, I don't even have VS or .NET installed any more!) but if you were to create a new app, add a button and a timer, set the timer with a duration of 500, and in the tick event, have it display a messagebox with something. In the click event of the button, start the timer, then have it start a loop where it just outputs to the debug window, and just keeps looping (this creates a busy loop, just to keep things busy) ... when you run it and click the button, it should start outputting to the debug window, and then a messagebox should pop up, and another, and another and another, and so on ad nauseum until you stop the program.

    It shouldn't even stop long enough for you to click the messagebox button to dismiss it. Like the Energizer Bunny, it should just keep going and going and going and going....


    -tg
    Thanks for the response, but my experience with Timer-Controls argues against your statement; "the timer actually runs on a secondary thread". I've created test programs with two timers, or a timer and some other event. I've run a long process (Fibonacci calculation) in one timer event. When the Fibonacci calculation is in process (without any DoEvents in the loop, actually a recursion), a second timer that simply updates a time display every second stops, until the Fibonacci calculation terminates. So I see no evidence that the Timer is running in a secondary thread.

    Mickey

  4. #4
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,853

    Re: DoEvents/Timer clarification requested.

    Quote Originally Posted by MickeyXm View Post
    The implication being the within a Timer-Event, processes executed there will function virtually as independent threads.
    That part isn't correct. Unless we jump through the relatively high hurdles, we must remember that VB6 is always single-threaded. And that's inclusive of any DLLs, OCXs, and other in-process calls it makes.

    Personally, I always think of the thread (the single thread) as being in one of two places: 1) somewhere in my program executing my code, or 2) in Windows, watching for something that would fire an event in my code (which would return the thread to my code). And it's important to realize that the thread can't be in both of those places at the same time.

    (I suppose a third place it could be is down in some DLL that I've called such as an API call, but I tend to think of that as very similar to just being in my code.)

    Now, if we (our VB6 program) have control of the thread, absolutely nothing else is going to happen (including events) until we release control (giving it back to Windows). And that includes timer events, click events, and anything other events.

    And the one exception to that is if/when we call DoEvents. That's the only way we can hand control of the thread back to windows before some long loop has completed. I personally think of DoEvents very like a call to some procedure: My code pauses, the procedure does its thing, when the procedure is done it returns the thread to the caller, and then the caller's code starts executing again. That's very much how DoEvents works as well. However, rather than giving the thread to my named procedure, it gives it back to Windows and says, if there are any events in the queue for my process, go ahead and execute them, and, when done, give the thread back to me.

    Many people consider DoEvents to be quite evil, and there are good reasons for that. Here's a trivial example of why. Let's say you've got some algorithm that takes 60 seconds to run. And you've decided to sprinkle DoEvents throughout this algorithm. Furthermore, when this algorithm is executing, you don't disable any buttons on the form that started it. Under these conditions, the user might click on the "Run Algorithm" many times, iteratively (almost recursively) starting it many times. The first time that button is clicked, the algorithm will start, the second time the button is clicked, the first algorithm will pause, but the start again, the third time, the second execution will pause starting a third, and so on. Module and static variables in the algorithm can become a total mess.

    With that, I suppose I'll stop. Maybe that'll help.

    Good Luck,
    Elroy

    EDIT1: One more thing. It's good to remember that DoEvents only applies to our process. Using DoEvents has nothing to do with possibly giving timeslices to other programs that may be executing. The concepts of task-swapping and multi-tasking are at an entirely different level than anything to do with DoEvents.
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  5. #5
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,853

    Re: DoEvents/Timer clarification requested.

    Here's some code that rather conclusively shows that the timer is in the same thread. A new project with a Form1. Put a timer control (Timer1) on it, and also a button (Command1).

    Execute the code, the timer will start firing (every 1/5th second), and then click Command1. The perpetual loop will start executing, but the timer events will never get through.

    Here's the code for Form1:
    Code:
    
    Option Explicit
    Private Declare Sub Sleep Lib "kernel32.dll" (ByVal dwMilliseconds As Long)
    
    Private Sub Command1_Click()
        Do
            Sleep 100
            Debug.Print ".";
         Loop
    End Sub
    
    Private Sub Form_Load()
        Timer1.Interval = 200
        Timer1.Enabled = True
    End Sub
    
    Private Sub Timer1_Timer()
        Debug.Print vbCrLf; "*** Timer event ***"; vbCrLf
    End Sub
    
    
    Take Care,
    Elroy

    EDIT1: And just as a further FYI, Sleep is something entirely different from DoEvents. Sleep simply pauses for the specified amount of time (without taking CPU cycles) but it does not allow other events in our process to fire. And I just used a Sleep so the dots wouldn't fly across the Debug window quite so fast.
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  6. #6

    Thread Starter
    Member
    Join Date
    Jun 2018
    Posts
    34

    Re: DoEvents/Timer clarification requested.

    Quote Originally Posted by Elroy View Post
    That part isn't correct. Unless we jump through the relatively high hurdles, we must remember that VB6 is always single-threaded. And that's inclusive of any DLLs, OCXs, and other in-process calls it makes.

    Personally, I always think of the thread (the single thread) as being in one of two places: 1) somewhere in my program executing my code, or 2) in Windows, watching for something that would fire an event in my code (which would return the thread to my code). And it's important to realize that the thread can't be in both of those places at the same time.

    (I suppose a third place it could be is down in some DLL that I've called such as an API call, but I tend to think of that as very similar to just being in my code.)

    Now, if we (our VB6 program) have control of the thread, absolutely nothing else is going to happen (including events) until we release control (giving it back to Windows). And that includes timer events, click events, and anything other events.

    And the one exception to that is if/when we call DoEvents. That's the only way we can hand control of the thread back to windows before some long loop has completed. I personally think of DoEvents very like a call to some procedure: My code pauses, the procedure does its thing, when the procedure is done it returns the thread to the caller, and then the caller's code starts executing again. That's very much how DoEvents works as well. However, rather than giving the thread to my named procedure, it gives it back to Windows and says, if there are any events in the queue for my process, go ahead and execute them, and, when done, give the thread back to me.

    Many people consider DoEvents to be quite evil, and there are good reasons for that. Here's a trivial example of why. Let's say you've got some algorithm that takes 60 seconds to run. And you've decided to sprinkle DoEvents throughout this algorithm. Furthermore, when this algorithm is executing, you don't disable any buttons on the form that started it. Under these conditions, the user might click on the "Run Algorithm" many times, iteratively (almost recursively) starting it many times. The first time that button is clicked, the algorithm will start, the second time the button is clicked, the first algorithm will pause, but the start again, the third time, the second execution will pause starting a third, and so on. Module and static variables in the algorithm can become a total mess.

    With that, I suppose I'll stop. Maybe that'll help.

    Good Luck,
    Elroy

    EDIT1: One more thing. It's good to remember that DoEvents only applies to our process. Using DoEvents has nothing to do with possibly giving timeslices to other programs that may be executing. The concepts of task-swapping and multi-tasking are at an entirely different level than anything to do with DoEvents.
    Elroy,

    You'll note that my experimental findings completely agree with what you are saying; VB6 is single threaded; which is what I always understood. My original post was looking for an explanation of the statement in the the DoEvents-Function help, which again I quote: "DoEvents is most useful for simple things like allowing a user to cancel a process after it has started, for example a search for a file. For long-running processes, yielding the processor is better accomplished by using a Timer, or delegating the task to an ActiveX EXE component"

    Given that I understand VB6 to be single-threaded, I don't understand the statement; "For long-running processes, yielding the processor is better accomplished by using a Timer". They (MS) appear to be stating that using a Timer in place of DoEvents would make things better. I was looking for and explanation of what the author of the help statement was suggesting, or simply statement that's it's wrong.

    I also completely understand the advantage of using an ActiveX, but again the help file statement can be interpreted to say, for long processes, instead of DoEvents, use a Timer OR an ActiveX. This did not make any sense to me given that I know VB6 is single threaded.

    Thanks, Mickey

  7. #7
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,853

    Re: DoEvents/Timer clarification requested.

    Hi Mickey,

    Here's how I'd read that statement about the timer. I'd stand your thinking on its head. What I think they're saying is this:

    Rather than use a long-running-loop, somehow set things up such that small pieces of it are done in a timer's event. Maybe declare a Static variable in the timer's event that acts much like a loop index, but it's just incremented each time the timer fires. Then, the loop disappears and just becomes the timer's event until the process is completed.

    I hope that makes sense.

    Take Care,
    Elroy

    EDIT1: That approach could also prevent you from repeatedly running the long process. Just check the timer's "enabled" property in the button that starts it. If it's enabled, don't let the button do anything because it's not finished from the previous time it was clicked.

    EDIT2: And just as a further FYI, done as a timer's event, each time the event did an iteration, control would be returned to Windows, allowing other events to fire. Therefore, no need for any usage of DoEvents.
    Last edited by Elroy; Jun 20th, 2018 at 10:12 AM.
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  8. #8

    Thread Starter
    Member
    Join Date
    Jun 2018
    Posts
    34

    Re: DoEvents/Timer clarification requested.

    Quote Originally Posted by Elroy View Post
    Hi Mickey,

    Here's how I'd read that statement about the timer. I'd stand your thinking on its head. What I think they're saying is this:

    Rather than use a long-running-loop, somehow set things up such that small pieces of it are done in a timer's event. Maybe declare a Static variable in the timer's event that acts much like a loop index, but it's just incremented each time the timer fires. Then, the loop disappears and just becomes the timer's event until the process is completed.

    I hope that makes sense.

    Take Care,
    Elroy

    EDIT1: That approach could also prevent you from repeatedly running the long process. Just check the timer's "enabled" property in the button that starts it. If it's enabled, don't let the button do anything because it's not finished from the previous time it was clicked.

    EDIT2: And just as a further FYI, done as a timer's event, each time the event did an iteration, control would be returned to Windows, allowing other events to fire. Therefore, no need for any usage of DoEvents.
    Elroy,

    I hear what you're saying, but given the cryptic nature of the help text, you appear to be stretching a bit for an explanation. I will say you gave it a very worthy effort. But, frankly I think they screwed-up, if in only in making their statement ambiguous.

    Thanks, Mickey

  9. #9
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: DoEvents/Timer clarification requested.

    Quote Originally Posted by MickeyXm View Post
    The above excerpt appears to equate a Timer-Control event with an ActiveX? The implication being the within a Timer-Event, processes executed there will function virtually as independent threads.
    That isn't the implication at all.

    Timer controls post a deferred event. When it is raised you can perform the action you wanted to. In this case that would be your next quantum of "background" processing such as polling for some condition, performing computation, etc.

    So yes, you jumped to a conclusion the documentation never implied.

  10. #10

    Thread Starter
    Member
    Join Date
    Jun 2018
    Posts
    34

    Re: DoEvents/Timer clarification requested.

    Quote Originally Posted by dilettante View Post
    That isn't the implication at all.

    Timer controls post a deferred event. When it is raised you can perform the action you wanted to. In this case that would be your next quantum of "background" processing such as polling for some condition, performing computation, etc.

    So yes, you jumped to a conclusion the documentation never implied.
    dilettante,

    From my original post "Have I missed something in my interpretation of the excerpt above?"

    Clearly, I haven't "jumped" to any conclusions; I simply asked a question - I would hope in the future you would read the entire post, least you jump to conclusions.

    The information you have provided is very interesting, and perhaps even explanatory of the DoEvents-Function discussion. You clearly have more experience with VB so the Help statement at question may appear quite clear to YOU. My contention is that to average users the Help discussion is ambiguous at best. If the key-information to the statement relied on knowledge of the defer-ability of a time event that should have been mentioned and explained (or at least referenced) and not assuming the specific detail is known by the average user.

    Thanks for your response, Mickey
    Last edited by MickeyXm; Jun 21st, 2018 at 07:42 AM.

  11. #11
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    6,582

    Re: DoEvents/Timer clarification requested.

    dilettante's point was that you have made a conclusion which wasn't intended in the Help description.
    In particular, it seems you stopped reading after the sentence you quoted.

    The very next sentence following your quote says "In the latter case, the task can continue completely independent of your application, and the operating system takes case of multitasking and time slicing."

    The "latter case" in that sentence is referring to "delegating the task to an ActiveX EXE component". That implies that the "former case", i.e. using a timer is not like an ActiveX EXE component, and the operating system doesn't take care of multitasking and time slicing.

    It is specifically saying an ActiveX EXE is not equivalent to using a Timer.

    They can both be used to implement handling a long running process, but the paradigm of the two are different. They don't explain either method beyond that. It would be up to you to research how to use an ActiveX EXE to handle a long running process, and how that compares to using a timer to handle a long running process.
    In the case of using a timer to handle a long running process, you would find you have to break the process up into a series of short steps or phases. Each tick of the timer you would execute one of those short processing steps and then exit the event handler to wait for the next tick to continue the process. You would continue doing short bits of your process each tick until the whole process was complete.

    I'm sure they didn't feel like going into that detail in the description of DoEvents. If the user was interested in using a Timer or an ActiveX EXE, they would have to get help on those options specifically.

  12. #12
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Location
    Sofia, Bulgaria
    Posts
    5,120

    Re: DoEvents/Timer clarification requested.

    Actually for the ActiveX EXE case one would use a timer to begin the background task. That is on BeginLongTask method impl in Ax EXE one would just start a timer and return immediately. Then in the timer event the actual processing will be done in one go.

    For the in-process timer impl probably the actual processing will be split in shorter chunks as not to stutter the UI way too much. Although this approach is very inconvenient and totally unusable IMO. Much easier to redesign the in-process timer impl with DoEvents and a modal dialog for progress and a cancellation button

    cheers,
    </wqw>

  13. #13

    Thread Starter
    Member
    Join Date
    Jun 2018
    Posts
    34

    Re: DoEvents/Timer clarification requested.

    My point was that the ambiguity of the help description could lead to the conclusion I stated; not that it did.

  14. #14
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    6,582

    Re: DoEvents/Timer clarification requested.

    Well the statement boils down to:
    To accomplish objective X, the better approach is to use method A or method B.

    Should I infer that method A and method B must use the same approach based on the above statement?
    I don't think so. There are often multiple ways to accomplish something, but just as often those ways are different approaches to accomplish the task, not the same approach. To assume method A and method B must be equivalent in execution is one of those cases used in logic classes to show a faulty conclusion not based on the facts presented.

    You asked "Have I missed something in my interpretation of the excerpt above?", and I think the answer is yes. That excerpt is taken alone, out of context without the following sentence that tries to clarify the fact that the two options are not the same approach, and that the reader shouldn't assume that they are.

    Taking that one excerpt alone and out of context doesn't have enough information in it to make any "interpretation" about how to implement a long running process in either method, or what those methods entail. You've came to a conclusion that the methods were equivalent, where at best you could entertain the possibility that the methods might be equivalent (which is why they added the next sentence to try to dissuade you from that assumption), but you would need to do further research, i.e. either reading up on the two approaches, or empirical analysis of your assumptions. It appears you took the latter approach of testing your assumption, which is good. You definitely can't rely on simply reading about a concept and make the assumption that you fully understand the concept and have no need of testing your "understanding".

  15. #15
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: DoEvents/Timer clarification requested.

    Quote Originally Posted by MickeyXm View Post
    My point was that the ambiguity of the help description could lead to the conclusion I stated; not that it did.
    FWIW -
    I do find the Timer-part confusing as well - especially this snippet here:
    "...yielding the processor is better accomplished by using a Timer..."

    Maybe it's my understanding of the english-language (since my online-dict says,
    that "yielding" is used sometimes in the meaning of "harvesting" -> as in "yielding a profit",
    but since it was used in context with DoEvents, I think it was meant in the usual sense
    when we talk about CPU-resources ("*releasing* a few cycles of computing-power").

    <shrug>

    Olaf

  16. #16
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    6,582

    Re: DoEvents/Timer clarification requested.

    If you remember Windows 3.x, the OS was a cooperative multitasking environment. If a process went into an long running process loop without yielding the processor, the whole OS was frozen and you couldn't do anything. Since the beginning with VB1, a timer control was provided that would tick up to 18.2 times per second (faster with later systems, of course) so that you could execute small bits of a long running process each tick and then exit the tick event handler so that you didn't hang up the OS.

    Using a timer was the preferred way of yielding the processor to other processes when running a Visual Basic program. Using DoEvents allowed for more intense use of the processor, but could be considered a bit greedy given the state of the OS on top of DOS days.

    Now, with the advent of multiple processors and preemptive multitasking, being cooperative in your use of the processor is not given a lot of consideration these days, but the basic infrastructure of how the timer was designed to be used in VB6 hasn't really changed from the beginnings of VB in 1991.

  17. #17
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,853

    Re: DoEvents/Timer clarification requested.

    This all seems so silly to me. If we take a postmodern view of the help language, we could argue that there are infinite interpretations of it. However, that's not what matters. What matters for us as programmers is that we develop understandings of our options to get things done. We have a long running algorithm? I see four options:

    1. Just write a procedure that does this algorithm, possibly putting DoEvents in it, and make sure we have everything disabled but a Cancel button before we call it.
    2. Break the algorithm into chucks (dilettante's quanta, or possibly single iterations of some loop) and put these chunks in a timer event. We still monitor for a Cancel global flag, and we check to make sure our timer is disabled before letting our Start button do anything on a second click.
    3. Write an out-of-process executable (possibly ActiveX), and let that process do the algorithm, with some inter-process communication for ready/running/complete status.
    4. Look into some of the multi-threading options in the CodeBank and spawn a second thread to do it, still designing things so that it's not called more than once if it's already running.


    Forget what the help system says. I think we all have those understandings, so we're all good to go ... thread closed.

    Y'all Take Care,
    Elroy
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  18. #18

  19. #19
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,853

    Re: DoEvents/Timer clarification requested.

    Quote Originally Posted by The trick View Post
    Elroy, there is also fibers.
    Hmmm, interesting. I've never heard of those before. However, in VB6, I'm not sure they provide us anything more than a well managed (i.e., disable things that shouldn't be clicked while it's running) procedure.

    To quote that page...

    The only state information maintained for a fiber is its stack, a subset of its registers, and the fiber data provided during fiber creation.
    It's also clear that it runs in the same thread, so there's no performance advantage. As far as "data provided during fiber creation", that just sounds like a set of arguments to a procedure, so the only advantages are a new stack and a few independent CPU registers. When in VB6, I almost never worry about the stack, never having overflowed it. And I truly never think of CPU registers when programming in VB6.

    I can certainly see how this is useful for assembly programming, or doing little tasks the OS would need to do. But I'll wait for someone to outline an advantage in VB6 before I get too excited.

    But hey, thanks for the pointer.

    Take Care,
    Elroy
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  20. #20

    Thread Starter
    Member
    Join Date
    Jun 2018
    Posts
    34

    Re: DoEvents/Timer clarification requested.

    Quote Originally Posted by Elroy View Post
    This all seems so silly to me. If we take a postmodern view of the help language, we could argue that there are infinite interpretations of it. However, that's not what matters. What matters for us as programmers is that we develop understandings of our options to get things done. We have a long running algorithm? I see four options:

    1. Just write a procedure that does this algorithm, possibly putting DoEvents in it, and make sure we have everything disabled but a Cancel button before we call it.
    2. Break the algorithm into chucks (dilettante's quanta, or possibly single iterations of some loop) and put these chunks in a timer event. We still monitor for a Cancel global flag, and we check to make sure our timer is disabled before letting our Start button do anything on a second click.
    3. Write an out-of-process executable (possibly ActiveX), and let that process do the algorithm, with some inter-process communication for ready/running/complete status.
    4. Look into some of the multi-threading options in the CodeBank and spawn a second thread to do it, still designing things so that it's not called more than once if it's already running.


    Forget what the help system says. I think we all have those understandings, so we're all good to go ... thread closed.

    Y'all Take Care,
    Elroy
    Elroy,

    Couldn't agree more!
    IMHO: The best phrase that applies here is "beating a dead horse"

    Mickey

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width