The old DoEvents and UserControls
-
Hi again. I am curious about a problem I am having with DoEvents. Now, I know DoEvents() is old school, and was only included in vb6 because vb6 did not support threading, at least not without a lot of difficulty. But the problem I have, is that I have ported a vb6 program over to vb.Net and there were a fair amount of DoEvents() lines due to a bunch of loops. These DoEvents lines were necessary because I had a Pause button that needs to stop execution when the user desires it. This worked OK in .Net, too...Until I included a TreeView usercontrol. Now, a fair amount of time is spent in the usercontrol since as the program scans folders, the TreeView is constantly updating to show the progress. In itself, that is a very inefficient way to show progress due to the amount of time processing the TreeView updates. But it looks rather cool as it progresses and I want to keep that look. The problem is that, I know that threading is the way to handle interruption of processing, but on the other hand, I just want this thing running as quickly as possible with the DoEvents lines...I can switch over to threading at some later date. But no matter where I put the DoEvents lines, they do not let the Pause button Click event to fire. My question is, does entering a usercontrol cause DoEvents in the stack to get cleared out? Or does it simply disregard any DoEvents lines altogether, whether they are inside the user control or not? Many thanks for any help on this. :)
-
Hi again. I am curious about a problem I am having with DoEvents. Now, I know DoEvents() is old school, and was only included in vb6 because vb6 did not support threading, at least not without a lot of difficulty. But the problem I have, is that I have ported a vb6 program over to vb.Net and there were a fair amount of DoEvents() lines due to a bunch of loops. These DoEvents lines were necessary because I had a Pause button that needs to stop execution when the user desires it. This worked OK in .Net, too...Until I included a TreeView usercontrol. Now, a fair amount of time is spent in the usercontrol since as the program scans folders, the TreeView is constantly updating to show the progress. In itself, that is a very inefficient way to show progress due to the amount of time processing the TreeView updates. But it looks rather cool as it progresses and I want to keep that look. The problem is that, I know that threading is the way to handle interruption of processing, but on the other hand, I just want this thing running as quickly as possible with the DoEvents lines...I can switch over to threading at some later date. But no matter where I put the DoEvents lines, they do not let the Pause button Click event to fire. My question is, does entering a usercontrol cause DoEvents in the stack to get cleared out? Or does it simply disregard any DoEvents lines altogether, whether they are inside the user control or not? Many thanks for any help on this. :)
All DoEvents does is process any pending windows messages sitting in the apps window message queue. It's not a second message pump, but it does suspend everything in the UI thread and handles the remaining messages, then it lets UI thread processing resume as normal. There is a difference though. The old VB6 DoEvents called Thread.Sleep, where as the .NET implementation does not. I'd serisouly consider scrapping the DoEvents stuff as soon as possible and transfer the long-running work to either background threads, BackgroundWorker, or Tasks. Doing so will take a considerable rewrite of your code.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
All DoEvents does is process any pending windows messages sitting in the apps window message queue. It's not a second message pump, but it does suspend everything in the UI thread and handles the remaining messages, then it lets UI thread processing resume as normal. There is a difference though. The old VB6 DoEvents called Thread.Sleep, where as the .NET implementation does not. I'd serisouly consider scrapping the DoEvents stuff as soon as possible and transfer the long-running work to either background threads, BackgroundWorker, or Tasks. Doing so will take a considerable rewrite of your code.
A guide to posting questions on CodeProject[^]
Dave KreskowiakDave Kreskowiak wrote:
Doing so will take a considerable rewrite of your code.
That is exactly what I am concerned about. I am trying to get out a v1 with as much speed as possible, w/o rushing to miss errors in the code.
Dave Kreskowiak wrote:
All DoEvents does is process any pending windows messages sitting in the apps window message queue.
That is where my question lies, and I am just as much academically interested in why it is not working, as I am trying to get v1 out the door. Since the Pause button click is an event, DoEvents SHOULD catch that event sitting in the stack waiting to be processed. Unless something is throwing it out. Could the problem be that every time I pass through the usercontrol, any DoEvents processed there for the Pause button in the UI are ignored? In other words, in trying to get my UI's Pause button to respond to DoEvents in the usercontrol, is it of no use in the usercontrol since it is occurring inside a different class and not the general UI where the Pause button is located?
-
Dave Kreskowiak wrote:
Doing so will take a considerable rewrite of your code.
That is exactly what I am concerned about. I am trying to get out a v1 with as much speed as possible, w/o rushing to miss errors in the code.
Dave Kreskowiak wrote:
All DoEvents does is process any pending windows messages sitting in the apps window message queue.
That is where my question lies, and I am just as much academically interested in why it is not working, as I am trying to get v1 out the door. Since the Pause button click is an event, DoEvents SHOULD catch that event sitting in the stack waiting to be processed. Unless something is throwing it out. Could the problem be that every time I pass through the usercontrol, any DoEvents processed there for the Pause button in the UI are ignored? In other words, in trying to get my UI's Pause button to respond to DoEvents in the usercontrol, is it of no use in the usercontrol since it is occurring inside a different class and not the general UI where the Pause button is located?
The problem is in the code that is looking for the flag to tell it to pause. The convesion from VB6 to .NET does NOT guarantee that the code is going to run like it did under VB6. Hell, it's not even guaranteed to compile! The problem does not appear to be with DoEvents, but with the code that you're trying to pause. Since we know nothing about that code and when the "pause" button does, it's impossible to say waht's going on.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
The problem is in the code that is looking for the flag to tell it to pause. The convesion from VB6 to .NET does NOT guarantee that the code is going to run like it did under VB6. Hell, it's not even guaranteed to compile! The problem does not appear to be with DoEvents, but with the code that you're trying to pause. Since we know nothing about that code and when the "pause" button does, it's impossible to say waht's going on.
A guide to posting questions on CodeProject[^]
Dave KreskowiakThe Pause button click event is not even firing to set the flag, except when the program is currently in my Form1 class, where that button is located. That is what it SEEMS like, anyway. My take on it is that when I try the Pause button while execution is inside the treeview usercontrol, (where execution seems to be spending the majority of its time under certain conditions) the button's click event can't fire because the program is not currently in Form1 to process it. When I notice this the most, is when the treeview is cycling through a bunch of files in some folder, one after the other. If a file does not meet a certain set of criteria, it immediately moves to the next file in the folder, and this occurs rapidly. Since the treeview must update for every change in node selection for every file, the code is spending a lot of time in the usercontrol just spitting out updates to the treeview. I think that is when my Pause button Click event fails to fire. And I mean explicitly that...I can put a breakpoint in the button's Click event, and it never triggers. When a scan of the treeview completes, the Pause button responds immediately.
-
The Pause button click event is not even firing to set the flag, except when the program is currently in my Form1 class, where that button is located. That is what it SEEMS like, anyway. My take on it is that when I try the Pause button while execution is inside the treeview usercontrol, (where execution seems to be spending the majority of its time under certain conditions) the button's click event can't fire because the program is not currently in Form1 to process it. When I notice this the most, is when the treeview is cycling through a bunch of files in some folder, one after the other. If a file does not meet a certain set of criteria, it immediately moves to the next file in the folder, and this occurs rapidly. Since the treeview must update for every change in node selection for every file, the code is spending a lot of time in the usercontrol just spitting out updates to the treeview. I think that is when my Pause button Click event fails to fire. And I mean explicitly that...I can put a breakpoint in the button's Click event, and it never triggers. When a scan of the treeview completes, the Pause button responds immediately.
treddie wrote:
When I notice this the most, is when the treeview is cycling through a bunch of files in some folder, one after the other. If a file does not meet a certain set of criteria, it immediately moves to the next file in the folder, and this occurs rapidly.
So does this code have a DoEvents in it that gets called kind of frequently??
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
treddie wrote:
When I notice this the most, is when the treeview is cycling through a bunch of files in some folder, one after the other. If a file does not meet a certain set of criteria, it immediately moves to the next file in the folder, and this occurs rapidly.
So does this code have a DoEvents in it that gets called kind of frequently??
A guide to posting questions on CodeProject[^]
Dave KreskowiakI tried DoEvents every which way I could...In every loop and inside the usercontrol. My impression is that the ones in the usercontrol never work at all. The ones in the main form work when they can get a breather...That is, when execution is not currently inside the usercontrol code.
-
I tried DoEvents every which way I could...In every loop and inside the usercontrol. My impression is that the ones in the usercontrol never work at all. The ones in the main form work when they can get a breather...That is, when execution is not currently inside the usercontrol code.
To make sure, I ran my own tests on DoEvents in a UserControl and it does work. The problem has to be somewhere else as far as I can tell. Again, we can't see your code, so it's impossible to tell you what's going on.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
To make sure, I ran my own tests on DoEvents in a UserControl and it does work. The problem has to be somewhere else as far as I can tell. Again, we can't see your code, so it's impossible to tell you what's going on.
A guide to posting questions on CodeProject[^]
Dave KreskowiakDang. I was afraid of that. I think i buggered it up! :( I'm going to have to go through it with a fine tooth comb, and figure out what I did, then. Which may just be an exercise in understanding something I will never use again. As I research threading more, there might be a reasonably easy way of making the transition to it.