Timer for program (non graphic)

  • Thread starter Thread starter Joris De Groote
  • Start date Start date
J

Joris De Groote

Hi,

I have wrote a program that checks for files and moves these files to the
correct folders when they come in. Everything works fine. However I always
have to start that program manually. I have been trying to make the program
(wich has no UI) to keep running and let it execute everything once every
few minutes (depending on how the timer is set).

Can anyone tell me how I can get a timer in the program so the program keeps
running? I can add a timer, but the program just quits when everything has
run. I don't want it to close.

Thanks
Joris
 
Joris De Groote said:
Hi,

I have wrote a program that checks for files and moves these files to the
correct folders when they come in. Everything works fine. However I always
have to start that program manually. I have been trying to make the
program (wich has no UI) to keep running and let it execute everything
once every few minutes (depending on how the timer is set).
Click to expand...

Are you using a Console Application?
Can anyone tell me how I can get a timer in the program so the program
keeps running? I can add a timer, but the program just quits when
everything has run. I don't want it to close.
Click to expand...

You are using the System.Timer namespace?

This example came from VS Help for VB.

Imports System
Imports System.Timers

Public Class Timer1

Public Shared Sub Main()
' Normally, the timer is declared at the class level, so
' that it doesn't go out of scope when the method ends.
' In this example, the timer is needed only while Main
' is executing. However, KeepAlive must be used at the
' end of Main, to prevent the JIT compiler from allowing
' aggressive garbage collection to occur before Main
' ends.
Dim aTimer As New System.Timers.Timer()

' Hook up the Elapsed event for the timer.
AddHandler aTimer.Elapsed, AddressOf OnTimedEvent

' Set the Interval to 2 seconds (2000 milliseconds).
aTimer.Interval = 2000
aTimer.Enabled = True

Console.WriteLine("Press the Enter key to exit the program.")
Console.ReadLine()

' Keep the timer alive until the end of Main.
GC.KeepAlive(aTimer)
End Sub

' Specify what you want to happen when the Elapsed event is
' raised.
Private Shared Sub OnTimedEvent(source As Object, e As ElapsedEventArgs)
Console.WriteLine("Hello World!")
End Sub
End Class

You do know about the FileSystemWatcher where it will check for a file
coming in to a folder and fire an event.

http://www.google.com/search?hl=en&q=FileSystemWatcher+vb.net&btnG=Google+Search
 
Joris,

This needs to be a "Service" instead of a console application.

Cor
 
Cor Ligthert said:
Joris,

This needs to be a "Service" instead of a console application.
Click to expand...

Why? One can certainly build a console application that will stay up and
running 24/7*365, until one tells it to shutdown, and it do everything that
a Service application can do in regards to the OP's solution.
 
Then when would you use a Service for me is this a typical way were a
service fits the best.
You can use a windows application as well for this, but for me it is as
using a bicycle to transport a piano.
It can be done.

Cor
 
Cor Ligthert said:
Then when would you use a Service for me is this a typical way were a
service fits the best.
Click to expand...

In this simple solution of an application using a timer and polling for
files in a directory, then why would the OP need a service to do it? I don't
see the reasoning

When I need an application to be monitored by a Human Being showing status,
progress, mission critical situations, etc, etc, then I'll use a Console
Application for that purpose.

If I need an application that can run unattended and be assured that the
application will be started again by itself if the machine is rebooted, then
I'll use a Service.

But you can do the same with an Console Appliaction as far as a machine
restart, with O/S or 3rd party solutions utilities.

You can use a windows application as well for this, but for me it is as
using a bicycle to transport a piano.
Click to expand...

A Windows application and a Console Application are two different things.

I have used Service and Console applications to do many things. And to be
honest, there is nothing I couldn't have done with a Service application
that I couldn't have done with a Console application that I have seen to
this point.

It all depends upon what the customer wants. If they wanted it to be a NT
Service application, then that's what they got. If they wanted to be a
Console application, then that's what they got.

Both of the solutions have the power to produce powerful .NET applications,
no doubt about it from my view point, with both being trucks to transport
that paino.
 
Feel free, feel free, I only told the OP that in my opinion a Service was
more dedicated to his problem. I know that it can be done with every
application. Even without it by puting it in the scheduler.

Cor
 
Cor Ligthert said:
Feel free, feel free, I only told the OP that in my opinion a Service was
more dedicated to his problem. I know that it can be done with every
application. Even without it by puting it in the scheduler.

Cor
Click to expand...
 
Even without it by puting it in the scheduler.
Click to expand...

I don't know what you are referring to here on this one, as you can
instantiate a timer off of the System.Timers.Timer in a Console as well as a
Service application to control time intervals, as well as Threads using
intervals.

Like I said, you can keep a Console application up and running 24/7*365, you
can have a Console restarted on a reboot, using the O/S Batch file system,
other O/S tools or other 3rd party tools and it can do just about anything a
Service can do in regards to creating or running a powerful .Net solution,
with few exceptions or limitations.

A Console application is on par with a Service application, if one knows how
to design and implement an application using the solution. It's more than a
bicycle, MVP.
 
For what is the is the program from Joris build for.

To communicate with clients over a console (Typical console operation)

To move files to other places smoothly done as there is time for that.
(Typical service operation)

That a lot of people use a Console operation because it act as a former Dos
operation (including Microsoft often does using old NT scripts), does not
mean that it is build for that.

Cor
 
Cor Ligthert said:
For what is the is the program from Joris build for.

To communicate with clients over a console (Typical console operation)
Click to expand...

That would be when necessary. You can communicate to an Event log as well
just like you can with NT service application. As a matter of fact, you can
have a screen sitting there that a NT Service application can communicate
to as well and you can call that a console if you like.
To move files to other places smoothly done as there is time for that.
(Typical service operation)
Click to expand...

I disagree as I have done it with both solutions. I have also gone out over
HTTP to connect to a Web service pulling XML data from the site, writing
files down to a file directory queue, processing those files (1, 000's of
them at a time) or processing was done on the fly in memory, extracted the
data from XML files or from memory to SQL Server or Oracle databases with
adds, updates and deletes in a ADO.NET transactional mode, using Oops
programming techniques in both solutions.

I did it first with .NET NT Service applications in C# and VB .NET. Then
when called to do the same thing with a .NET Console application, because
that's what the client wanted, I was able to do the same thing with .NET
Console solutions.

Both solutions being used had the ability to create XML serialized object
files down to a directory with sending the files off to other directories
local or over the LAN to be processed to Shares. Both .NET Console and NT
Service applications ran 24/7*365, which one being just a powerful as the
other.

BTW, these were multi threaded solutions.
That a lot of people use a Console operation because it act as a former
Dos operation (including Microsoft often does using old NT scripts), does
not mean that it is build for that.
Click to expand...

I guess .NET allows one to surpass the limitations you see with a Console
application , because I have done some serious things with both solutions,
that ran as smooth as a baby's bottom.

Maybe, I am too naive to know that I am not suppose to be doing this with a
Console application. <g>
 
Back
Top