Please explain why these are two 'No No !' commands.

Hi, in recent days, I've been admonished for using two commands: 'My.Application.DoEvents' and 'End'.
If they are so bad why are they still available?

Ok... I have a project, at the end of which, or if there's a user error; I want to display a short message and close the program. I do not want to use a MessageBox because I just want the program to close down, on it's own after just five seconds without intervention from the user... No buttons.

I'm not bothered that everything is put on hold for those five seconds because this program only runs once as a 'Start Up' program, and five seconds is a drop in the ocean these days compared to the time it takes my machine to boot-up.

'No No' 1: The process has to be able to 'see' the Timer1.Tick so I call: My.Application.DoEvents() while it waits.

'No No' 2: When the timer 'ticks' Timer1 is disabled and the While Loop completes... Fine, so what's next? Me.Close(), close the program: Right ? Does the program close? NO... It just carries on as if nothing had said Stop. So... I add the second 'No No': End... Problem solved.

Where's the harm ? What's so tragic ?

vb.net Code:

Private Sub Timer1_Tick() Handles Timer1.Tick
 
      Timer1.Enabled = False
 
   End Sub
 
   Private Sub All_Done(ByVal err As Boolean)
 
      Timer1.Enabled = True
      If err Then Label2.Visible = True
      While Timer1.Enabled
         My.Application.DoEvents()
      End While
      Me.Close()
      End
 
   End Sub

Poppa.

I use:

System.Windows.Forms.Application.Exit()

instead of end. Someone might come along and smack me though :D

I'm not going to address the "no nos". There are people here better qualified then me for that.

End... does that... it just ends... no cleanup or anything... application.exit would be the more preferrable approach... at lest it attempts to run the clean up process...

Using End... it's like taking the keys out of the ignition, while still traveling 60mph...

as for your example.... oi... the busy loop is bad because it's not needed and can drive up your CPU usage... if you want to pause things... that's fine, start the timer and be done with it... when the timer fires off, disable it (so it doesn't fire again) and then do what you need to do and exit the application.

Code:

---

Private Sub Timer1_Tick() Handles Timer1.Tick
 
      Timer1.Enabled = False
      Me.Close() ' -- if this alone doesn't close the app too, then use the following line:
      'System.Windows.Forms.Application.Exit()
 
  End Sub
 
  Private Sub All_Done(ByVal err As Boolean)
 
      If err Then Label2.Visible = True
      Timer1.Enabled = True
 
  End Sub

---

If the app isn't unloading, then there's some resource that's still out there... an open form perhaps? Check your application settings, to see what terminates the application: all forms close, main form closes, etc...

-tg

Here are a couple of articles on the Application.DoEvents topic:

http://www.codinghorror.com/blog/200...ents-evil.html

http://www.codinghorror.com/blog/200...revisited.html

Quote:

---

Originally Posted by Poppa Mintin

Hi, in recent days, I've been admonished for using two commands: 'My.Application.DoEvents' and 'End'.
If they are so bad why are they still available?

Ok... I have a project, at the end of which, or if there's a user error; I want to display a short message and close the program. I do not want to use a MessageBox because I just want the program to close down, on it's own after just five seconds without intervention from the user... No buttons.

I'm not bothered that everything is put on hold for those five seconds because this program only runs once as a 'Start Up' program, and five seconds is a drop in the ocean these days compared to the time it takes my machine to boot-up.

'No No' 1: The process has to be able to 'see' the Timer1.Tick so I call: My.Application.DoEvents() while it waits.

'No No' 2: When the timer 'ticks' Timer1 is disabled and the While Loop completes... Fine, so what's next? Me.Close(), close the program: Right ? Does the program close? NO... It just carries on as if nothing had said Stop. So... I add the second 'No No': End... Problem solved.

Where's the harm ? What's so tragic ?

vb.net Code:

Private Sub Timer1_Tick() Handles Timer1.Tick
 
      Timer1.Enabled = False
 
   End Sub
 
   Private Sub All_Done(ByVal err As Boolean)
 
      Timer1.Enabled = True
      If err Then Label2.Visible = True
      While Timer1.Enabled
         My.Application.DoEvents()
      End While
      Me.Close()
      End
 
   End Sub

Poppa.

---

First of all I could not replicate the problem with the code as - is.

Code:

---


    Private Sub Button2_Click_1(sender As Object, e As EventArgs) Handles Button2.Click
        All_Done(False)
    End Sub

    Private Sub Timer1_Tick(sender As Object, e As EventArgs) Handles Timer1.Tick
        Timer1.Enabled = False
    End Sub

    Private Sub All_Done(ByVal err As Boolean)

        Timer1.Enabled = True
        If err Then Label2.Visible = True
        While Timer1.Enabled
            My.Application.DoEvents()
        End While
        Me.Close()

    End Sub

---

Here is the cautionary statement from the documentation, "Calling this method causes the current thread to be suspended while all waiting window messages are processed. If a message causes an event to be triggered, then other areas of your application code may execute. This can cause your application to exhibit unexpected behaviors that are difficult to debug..."

Do you know every piece of code that may execute when you execute the DoEvents? As I said the code closed without the End statement so I wonder if there isn't other code causing it not to end? Do you have anything in the Close event?

What do you want your code to do?

Quote:

---

Originally Posted by dbasnett

Do you have anything in the Close event?
What do you want your code to do?

---

I have a 'Diary' program which I originally wrote in VB3.0 hundreds of years ago, and have up-dated from time to time, the last time was a year or so back using VB2008.

I also have a program which I wrote more recently when two programs were viying for the desktop when I start-up. The up-date of this second program is my current project.

Basically I call this one instead of the two others separately so that I can start the second when I detect that the Diary has completed.

Previously this program gave a running comentry on what it was doing, which many times was a waste of time and effort because by the time it had displayed one message the program would be two or more steps ahead of it.

So I decided that I'd only 'Show' the form when there was an error to report... one of the two programs was already running when it starts... I don't know how that could happen, but there it is... Or if maybe one or other of the filepaths have changed, 'File not found'... Again I don't know how that could happen... Or when the second program closes, it would just bring up a message to say that the PC's internal clock had been updated, display it for about five seconds and close. Oh, and when it's completed up-dating the clock, it plays a 'Ding-dong' to attract attention to the message.

Label2 is only displayed if one or other of the two programs is running when the program starts.

So... at the point in the project where the 'All_Done' subroutine is called, Form1 has been told to display (Me.Show)
Label1 will have a new text (From "")
And possibly Label2, which has a pre-determind text, will be changed to 'Visible'.
Timer1 (Interval = 5000) will be enabled.

I've shown my code for 'All_Done' and 'Timer1_Tick', here follows the last part of the main subroutine, ( It's NOT in 'Form1_Load' )

vb.net Code:

'
 
      While F(3)
         For Each P As Process In Process.GetProcesses
            If P.ProcessName = "Neutron" Then F(3) = False 'Neutron is running.
         Next
      End While
      While F(4)
         F(4) = False   'Neutron has closed.
         For Each P As Process In Process.GetProcesses
            If P.ProcessName = "Neutron" Then
               F(4) = True 'No, hang-on...   Neutron is still running.
            End If
         Next
      End While
      My.Computer.Audio.Play(My.Resources.doorbell, AudioPlayMode.WaitToComplete)
      Txt = "Computer's Clock corrected at:" & vbCrLf & Now.ToString
      Show_Txt(Txt)
      All_Done(False)
 
   End Sub

And this is the code for 'Show_Txt'

vb.net Code:

Private Sub Show_Txt(ByVal Stg As String)
 
      Me.Show()
      Label1.Visible = True
      Label1.Text = Stg
 
   End Sub

Poppa.

vb.net Code:

While F(3)
         For Each P As Process In Process.GetProcesses
            If P.ProcessName = "Neutron" Then F(3) = False 'Neutron is running.
         Next
      End While
      While F(4)
         F(4) = False   'Neutron has closed.
         For Each P As Process In Process.GetProcesses
            If P.ProcessName = "Neutron" Then
               F(4) = True 'No, hang-on...   Neutron is still running.
            End If
         Next
      End While

Ok I've no idea what the purpose of F(3) and F(4) is in the wider context but don't those two loops do exactly the same job, ie. determine whether 'Neutron' is running? And do you really want to hold up the program in its entirety when it is? As has been suggested you should activate the timer only when it becomes necessary to check whether Neutron is running. On tick, if it is running, do nothing. If it is not, update the displays, and stop the timer.

DoEvents isn't so bad, but the busy wait certainly is. By spinning around a DoEvents like that you are accomplishing nothing, but you certainly aren't doing nothing. Instead, you are causing the CPU to run flat-out, with all the attendant problems that causes, while accomplishing nothing. The ideal solution is to have the CPU doing nothing when there is nothing to do.

In this case, you say you want the DoEvents in there so that the tick event gets handled. All other possible events would also get handled, and from your description, you really don't care about any of them. It sounds like there might not be anything that the user would do with the program during that interval, and the interval is only there for showing the message for a set amount of time before closing. If that's the case, the simplest solution is probably to get rid of the timer and the busy wait and just call Thread.Sleep(5000). Normally, you wouldn't want to do that, as it would freeze the app for five seconds. Nothing would happen, no events, no drawing, nothing. But that may be exactly what you want. The one drawback is that it wouldn't paint the screen, either, so if you dragged something else across the form it would just look white.

Quote:

---

Originally Posted by dunfiddlin

Ok I've no idea what the purpose of F(3) and F(4) is in the wider context but don't those two loops do exactly the same job, ie. determine whether 'Neutron' is running? And do you really want to hold up the program in its entirety when it is?

---

The two loops look the same but have different purposes, I first check that 'Neutron' is running, and then that it's completed. I've already done that with 'Diary', originally with F(0) and F(1). I need to know that each program has actually started before I can check that it's completed and move on to the next part of the project.

The original significance of F(0) to F(5) was to ensure the next event wasn't called until the previous one had completed, and to facilitate the 'running commentary' I mentioned in my first post. My re-hash made that redundant so I've now just changed the 'Flag' to a single Boolean and toggle the True / False test for each subsequent check.

Quote:

---

Originally Posted by Shaggy Hiker

DoEvents isn't so bad, but the busy wait certainly is. By spinning around a DoEvents like that you are accomplishing nothing, but you certainly aren't doing nothing.
...the simplest solution is probably to get rid of the timer and the busy wait and just call Thread.Sleep(5000). Normally, you wouldn't want to do that, as it would freeze the app for five seconds. Nothing would happen, no events, no drawing, nothing. But that may be exactly what you want. The one drawback is that it wouldn't paint the screen, either, so if you dragged something else across the form it would just look white.

---

I was never really happy with using 'DoEvents' in a loop like that, but in VB3.0 it seemed to work ok and it just got 'carried over'.
As you guess, the fact that the app is 'frozen' during the Wait Loops is of little moment because the form isn't even visible, the programs which have been called during them still work as they ought.

I liked the idea of removing the timer altogether, which I did and replaced it as you suggested with the (actually) ' Threading.Thread.Sleep(5000) ' command, this did prevent the painting of the message, but using just one 'DoEvents' before calling 'Sleep' solved that.

Having done that and tested it and found that everything still worked correctly, I removed the 'End' statement and re-tested but the program still just continued totally without regard to the 'Me.Close'...

I then tried the 'System.Windows.Forms.Application.Exit' suggested by two of the other replies, that too failed to close the program. I've gone back to my original close down method.
The problem only occurs when I test for errors, when I simulate an 'already running' error, I get the error message ok, but as soon as the message clears, when the program should close, a second instance of the running program is started.

Poppa.

Quote:

---

The two loops look the same but have different purposes, I first check that 'Neutron' is running, and then that it's completed.

---

Me no understand why you need do that especially if you're the author of all the programs involved. Would it not be simpler to have the one that's closing launch the next one in the chain in its closing events?

Quote:

---

Originally Posted by Poppa Mintin

...

Having done that and tested it and found that everything still worked correctly, I removed the 'End' statement and re-tested but the program still just continued totally without regard to the 'Me.Close'...

I then tried the 'System.Windows.Forms.Application.Exit' suggested by two of the other replies, that too failed to close the program. I've gone back to my original close down method.
The problem only occurs when I test for errors, when I simulate an 'already running' error, I get the error message ok, but as soon as the message clears, when the program should close, a second instance of the running program is started.

Poppa.

---

If the application isn't closing properly when you expect it to (using me.close or Application.Exit) then you have a coding problem.

[DoEvents - it's a legacy when threading was not available to VB. It's not necessary, today, and is very easy to abuse. It's a kludge that helps perpetuate VB as a 'toy' language].

Quote:

---

Originally Posted by dunfiddlin

Me no understand why you need do that especially if you're the author of all the programs involved. Would it not be simpler to have the one that's closing launch the next one in the chain in its closing events?

---

I have to admit that that hadn't occurred to me... But I'm not the author of Neutron... A very nice little utility for up-dating the on-board clock, and I think I'd still have the same problem when reporting 'File C:\Neutron\Neutron.exe not found'.
Also I'd still have to check that Neutron had opened and closed, I can't just check that it's not running because the check might well complete Before Neutron has started... And I'd still need to use 'DoEvents' to display the message to say that the PC's internal clock had been updated.

Neat suggestion, but I can't see it making much difference. I tried to get to grips with Multi-threading without success, I'm still trying to understand it, I'm using Nyia's explanation in the Code Bank but I've not figured out how to modify it for my own use Yet.
I took the suggestion, in another thread, to go back to square one and start to re-learn VB from scratch and I'm doing that; except of course, as this particular thread shows, everyday life get's in the way.

Poppa.

I don't know what version of Windows you are running, but if you have an internet connection you can have windows automatically set the time from a NTP server.

Quote:

---

Originally Posted by dbasnett

I don't know what version of Windows you are running, but if you have an internet connection you can have windows automatically set the time from a NTP server.

---

I assume you're referring to the built-in MS option, and you're quite right of course and that's fine if you're logged on at the scheduled time, I got fed-up with my clock drifting off because I was either too early or too late, and even then I found it a bit unreliable.
This nice little utility takes a few seconds to do the job Every Time I boot-up my machine, no problems.

Oh, and if it's of any interest, my OS is Win.7 Pro. 64Bit.

Poppa.

You can change the interval that Windows Internet Time updates. Here is a link that shows you how

http://www.vistax64.com/tutorials/89...-interval.html

I think the default is once per day.

edit: Do not set this value to low or the time server may block all of your request.

Quote:

---

Originally Posted by dbasnett

You can change the interval that Windows Internet Time updates. Here is a link that shows you how

http://www.vistax64.com/tutorials/89...-interval.html

I think the default is once per day.

edit: Do not set this value to low or the time server may block all of your request.

---

I was going to suggest that also.
FWIW, I have one my systems set to update every 2 hours (SpecialPollInterval = 7200 decimal) because the stupid thing gains 9 secs every hour and Windows default update is only once per week. It never got banned, although I never used Windows Time server, I changed it to one of the .gov servers.

Quote:

---

Originally Posted by Edgemeal

I was going to suggest that also.
FWIW, I have one my systems set to update every 2 hours (SpecialPollInterval = 7200 decimal) because the stupid thing gains 9 secs every hour and Windows default update is only once per week. It never got banned, although I never used Windows Time server, I changed it to one of the .gov servers.

---

I have mine set for four hours and use tick.

Quote:

---

Originally Posted by dbasnett

You can change the interval that Windows Internet Time updates. Here is a link that shows you how

http://www.vistax64.com/tutorials/89...-interval.html

I think the default is once per day.

edit: Do not set this value to low or the time server may block all of your request.

---

See what I mean ! What a phaff ! I just run Neutron every time I boot up... Simples !

Simples indeed. But completely useless in Edgemeal's 9 second an hour error example and causing you problems on start-up. So maybe you should take advantage of Windows own way of doing things after all by slipping this in at the start of your diary program?

vb.net Code:

Private Sub Form1_Load(sender As System.Object, e As System.EventArgs) Handles MyBase.Load
        Dim p As New Process
        p.StartInfo.FileName = "w32tm"
        p.StartInfo.Arguments = "/resync "
        p.StartInfo.CreateNoWindow = True
        p.StartInfo.UseShellExecute = False
        p.StartInfo.RedirectStandardOutput = True
        p.Start()
        If p.StandardOutput.ReadToEnd.Contains("completed successfully") Then
            Label1.Text = "Time Synchronised " & Now.ToString
        Else
            Label1.Text = "Unable to synchronise time at this time, which may or may not be " & Now.ToString
        End If
    End Sub

You still sync on boot-up but within the program you really want to see and no messing about waiting for stuff to happen.

By the way, you didn't need the .DoEvents before the Sleep call, either. As you noted, the paint event was not getting through before the thread slept, during which it wouldn't get through, either. DoEvents paused execution to let the app process any pending messages, one of which was the Paint event. The alternative to DoEvents, in this case, would be calling .Refresh on the control. This will force an immediate paint of the control, which is all you really need. The DoEvents is fine, though.

A lot of people would hate me for saying this but really there is no direct "no no" in development. It’s all a matter of preference and what is good practice or what is viewed as the best/industry standard. At the end of the say, if it works who cares? However, there are methods that work best or will work better than others in certain cases. As the developer, you need to make the choice of what method to use and use the method your most comfortable using. I'm self taught so I started out using bad methods but I later learned new ways and improved over time. Being a developer is about dedicating yourself and your life to endless life of learning and improving your skill set. What one guy views as best practice may conflict with your style or methods. I often think of it as crafting a piece of software. All craftsmen use the same tools and know the basics but use different/unique crafting process to accomplish the same task.

Quote:

---

Originally Posted by dunfiddlin

Simples indeed.
maybe you should take advantage of Windows own way of doing things after all by slipping this in at the start of your diary program?
You still sync on boot-up but within the program you really want to see and no messing about waiting for stuff to happen.

---

Brilliant ! I thought, Thank you dunfiddlin, exactly what I need... I'll see how that works. Started a new project, added a Label1 (and Button1 to close the app. more easily)

Copied and pasted in your code and tested it... I keep getting the 'Ooops it didn't work' message.
So... I added a couple of extra bits, (Lines 3, 4, 14, 22 and 23) as you can see: -

vb.net Code:

Private Sub Form1_Load(sender As System.Object, e As System.EventArgs) Handles MyBase.Load
 
      FileOpen(1, "C:\A Temp Store\Sync.txt", OpenMode.Output)
      Dim txt As String = ""
 
      Dim p As New Process
      p.StartInfo.FileName = "w32tm"
      p.StartInfo.Arguments = "/resync "
      p.StartInfo.CreateNoWindow = True
      p.StartInfo.UseShellExecute = False
      p.StartInfo.RedirectStandardOutput = True
      p.Start()
 
      txt = p.StandardOutput.ReadToEnd
 
      If p.StandardOutput.ReadToEnd.Contains("completed successfully") Then
         Label1.Text = "Time Synchronised " & Now.ToString
      Else
         Label1.Text = "Unable to synchronise time at this time, which may or may not be " & Now.ToString
      End If
 
      Print(1, txt)
      FileClose()
 
   End Sub

And Sync.txt only contains way, way less than I expected having tried to find the relevant data in the Debug 'Locals' watch page.

Quote:

---

Sync.txt
The following error occurred: The service has not been started. (0x80070426)

---

I've tried to see why the prosess didn't start, the only thing might be "p.StartInfo.UseShellExecute = False" but I reckon you deliberately set that to False, so that it doesn't open a form on the desktop was my first guess but I see the previous command probably does that. The only apparent result of changing the 'False' to 'True' is no message at all !
The only other possibility that I can see might be 'p.StartInfo.RedirectStandardOutput = True' which I don't understand... There's nothing to say where to redirect it to, and I'd rather not change it without understanding that one.

My PC is on-line, Neutron worked ok when I booted up.


Poppa.

With reference to 'Me.Close' and 'End' etc, I was taking a bit of time out looking through the Forum and spotted this: -

Quote:

---

(Posted by) rpmaurer

Program Wont Close
I have a program starting with FormA, and opens to Forms B, C, D, E, etc... When I close forms B, C, D, E, it doesn't close the program. So I added this tidbit of code:

Code:

---

Private Sub AnalysisMain_Closing(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.FormClosing
        Me.Close()
    End Sub

---

This just causes the program to freeze.

Im sure theres a simple solution here

Ryan

---

That sounds familiar I thought and read on...

A bit further on .paul wrote: -

Quote:

---

.paul

Re: Program Wont Close

Code:

---

Private Sub AnalysisMain_Closing(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.FormClosing
    Application.Exit
End Sub

---

---

That sounds good...
I took out 'End' and 'Me.Close', and replaced it with 'Application.Exit' and it worked fine...
Has that solved that part of my original question ? or have I just committed another No-No ?

Poppa.

Quote:

---

Originally Posted by Shaggy Hiker

By the way, you didn't need the .DoEvents before the Sleep call, either. As you noted, the paint event was not getting through before the thread slept, during which it wouldn't get through, either. DoEvents paused execution to let the app process any pending messages, one of which was the Paint event. The alternative to DoEvents, in this case, would be calling .Refresh on the control. This will force an immediate paint of the control, which is all you really need. The DoEvents is fine, though.

---

Thanks Shaggy Hiker
I replaced 'My.Application.DoEvents' with your suggestion 'Me.Refresh' and it worked (of course).

Thanks again, that's another No-No sorted !

Poppa.

Quote:

---

The following error occurred: The service has not been started. (0x80070426)

---

Drat. w32tm only works if Windows Time service is started which I've always assumed to be default but I guess isn't. Ok then ....

vb.net Code:

' add reference to System.ServiceProcess
 
        Private Sub Form1_Load(sender As System.Object, e As System.EventArgs) Handles MyBase.Load
 
        Dim sc As New ServiceProcess.ServiceController("Windows Time")
        Dim StartedByProcess As Boolean = False
        If sc.Status = ServiceProcess.ServiceControllerStatus.Stopped Then
            sc.Start()
            sc.WaitForStatus(ServiceProcess.ServiceControllerStatus.Running)
            StartedByProcess = True
        End If
 
        Dim p As New Process
        p.StartInfo.FileName = "w32tm"
        p.StartInfo.Arguments = "/resync "
        p.StartInfo.CreateNoWindow = True
        p.StartInfo.UseShellExecute = False
        p.StartInfo.RedirectStandardOutput = True
        p.Start()
 
        If p.StandardOutput.ReadToEnd.Contains("completed successfully") Then
            Label1.Text = "Time Synchronised " & Now.ToString
        Else
            Label1.Text = "Unable to synchronise time at this time, which may or may not be " & Now.ToString
        End If
 
        If StartedByProcess Then sc.Stop()
        sc.Dispose()
            
    End Sub

Quote:

---

Originally Posted by Poppa Mintin

I then tried the 'System.Windows.Forms.Application.Exit' suggested by two of the other replies, that too failed to close the program. I've gone back to my original close down method.
Poppa.

---

When I tried this, I typed in the whole of 'System.Windows.Forms.Application.Exit' I guess that was the error.

Poppa.

you obviously don't have an import for System.Windows.Forms then.
you should try putting a GoTo statement in your code + ask dbasnett what he thinks:D

Quote:

---

Originally Posted by dunfiddlin

Drat. w32tm only works if Windows Time service is started which I've always assumed to be default but I guess isn't. Ok then ....

---

I think this subject may be interesting more widely, so I've started a separate post for this topic...
(I hope that's ok ?)

Poppa.