Timer in class?

  • Thread starter Thread starter hermann leinen
  • Start date Start date
H

hermann leinen

Hello!

I want to migrate from VB6 to C#.

In VB6 I have a class that checks for mails each minute.
This mail-check class also instantiates a self-firing timer class
(cSelfTimer) because I did not want to put a timer in one of my forms.

It looks like this

Class clsMail

Private WithEvents cTmr as clsTimer

Private Sub cTmr_TimerEvent
'// Check for new mails
End sub

End ClsMail

Can somebody please tell me how I should do this in C#?

Should I write a class in C# that also has a timer class (if such
exists) in it, or what would be a nice way to do it in C#?

Thank you,
Hermann
 
hermann said:
Hello!

I want to migrate from VB6 to C#.

In VB6 I have a class that checks for mails each minute.
This mail-check class also instantiates a self-firing timer class
(cSelfTimer) because I did not want to put a timer in one of my forms.

What's "cSelfTimer"? A class you wrote from scratch? Something else?
[...]
Should I write a class in C# that also has a timer class (if such
exists) in it, or what would be a nice way to do it in C#?

It's not clear why you don't want to use the System.Windows.Forms.Timer
class, given a Forms application. However, with that restriction as
given, you can use either of the other Timer classes in .NET:
System.Threading.Timer, or System.Timers.Timer (the latter uses the
former…which to use depends mainly on which offers the API best suited
to your particular use).

Note that by not using System.Windows.Forms.Timer, you will have to deal
with cross-thread invocation issues yourself. If there's no interaction
at all with the GUI, that won't be an issue, but otherwise you may find
System.Windows.Forms.Timer to be the best choice after all.

Pete
 
cSelfTimer is class that uses the API SetTimer.
SetTimer calls a callback function within cSelfTimer at each timer event.
The class which "hosts" cSelfTimer receives the fire event because
cSelfTimer raises it.

I did it this because I didn't like to have separate forms just to host
controls like timers, WinSock, etc.

Did I understand it correctly that this is in fact how it should be done
in C#?
-> I should make a form and just place the timer on it and then when it
fires, I say something like (pseudocode)

Form1.Timer1.TimerEvent
someclass.MakeSomething

I hope I got it correctly.

Regards,
Hermann


Am 25.02.2010 08:51, schrieb Peter Duniho:
hermann said:
Hello!

I want to migrate from VB6 to C#.

In VB6 I have a class that checks for mails each minute.
This mail-check class also instantiates a self-firing timer class
(cSelfTimer) because I did not want to put a timer in one of my forms.

What's "cSelfTimer"? A class you wrote from scratch? Something else?
[...]
Should I write a class in C# that also has a timer class (if such
exists) in it, or what would be a nice way to do it in C#?

It's not clear why you don't want to use the System.Windows.Forms.Timer
class, given a Forms application. However, with that restriction as
given, you can use either of the other Timer classes in .NET:
System.Threading.Timer, or System.Timers.Timer (the latter uses the
former…which to use depends mainly on which offers the API best suited
to your particular use).

Note that by not using System.Windows.Forms.Timer, you will have to deal
with cross-thread invocation issues yourself. If there's no interaction
at all with the GUI, that won't be an issue, but otherwise you may find
System.Windows.Forms.Timer to be the best choice after all.

Pete
 
hermann said:
cSelfTimer is class that uses the API SetTimer.

What API SetTimer? The unmanaged SetTimer() function requires a window.
SetTimer calls a callback function within cSelfTimer at each timer event.
The class which "hosts" cSelfTimer receives the fire event because
cSelfTimer raises it.

I did it this because I didn't like to have separate forms just to host
controls like timers, WinSock, etc.

If you had any form at all, you could use that one for the timer. If
you're using the unmanaged SetTimer() function, you must have a window
handle for that (e.g. a form). If there's some VB6 function called
SetTimer() that doesn't require you to provide a window, it almost
certainly creates one on your behalf.

Which is all a long way of saying that if your current VB code uses
SetTimer() or anything related to it, that you are currently using a
window-associated timer, and the System.Windows.Forms.Timer timer will
be the most direct "drop-in" replacement for your needs.
Did I understand it correctly that this is in fact how it should be done
in C#?
-> I should make a form and just place the timer on it and then when it
fires, I say something like (pseudocode)

Form1.Timer1.TimerEvent
someclass.MakeSomething

I hope I got it correctly.

If you are using System.Windows.Forms.Timer, then yes…you can drag it
from the "Components" section of the Toolbox in the Designer, onto your
form, where it will wind up in the "components tray" below the design
area. You can select it there and set properties, such as the Interval
to use, and/or subscribe to the Tick event to create an event handler
that will be called every time the timer period elapses.

The timer will be available in your code, using the variable name
created for it by the Designer. By default, this will be "timer1", a
private field in your Form sub-class. You can use the Start() and
Stop() methods, or the Enabled property, to control whether the timer is
active.

MSDN has a lot more details, if the above is not sufficient.

Pete
 
Thanks for the reply.

Btw, no, I don't need a hwnd for the SetTimer function (it's the windows
api function), I am using ASM code and vtable manipulation to have it
callback directly in/on my function.

I only thought that Microsoft had perhaps invented something of that
kind on their own, but it seems not.

Thanks again,

Hermann

Am 25.02.2010 18:31, schrieb Peter Duniho:
 
hermann said:
Thanks for the reply.

Btw, no, I don't need a hwnd for the SetTimer function (it's the windows
api function),

Sure you do. You are allowed to pass NULL for the hWnd parameter, but
you still have to have a window somewhere, and you still need to be
dispatching messages for the window.
I am using ASM code and vtable manipulation to have it
callback directly in/on my function.

Why anyone would do that, I have no idea. Sounds like an awful
implementation. But regardless, it doesn't get you out of having to
have a window somewhere.
I only thought that Microsoft had perhaps invented something of that
kind on their own, but it seems not.

I also don't understand that comment. Something of what kind?
Something like SetTimer()? A timer that doesn't require a window? Both
exist in .NET. What else do you want?

Pete
 
Sure you do. You are allowed to pass NULL for the hWnd parameter, but
you still have to have a window somewhere, and you still need to be
dispatching messages for the window.


Why anyone would do that, I have no idea. Sounds like an awful
implementation. But regardless, it doesn't get you out of having to
have a window somewhere.


I also don't understand that comment. Something of what kind?
Something like SetTimer()? A timer that doesn't require a window? Both
exist in .NET. What else do you want?

Pete

Actually Peter - you don't need to have a window handle or a window to use
SetTimer. What you need to do is dispatch messages on the callign thread...

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;
using System.ComponentModel;

namespace SetTimerExample
{
class Program
{
private static bool done = false;
private static int count = 10;
private delegate void TimerProc(IntPtr hWnd, uint uMsg, uint idEvent, uint dwTime);

private struct POINT
{
public int X;
public int Y;
}

private struct MSG
{
public IntPtr hwnd;
public uint message;
public uint wParam;
public uint lParam;
public uint time;
public POINT pt;
}

[DllImport("user32", SetLastError=true)]
private static extern uint SetTimer ( IntPtr hWnd, uint nIDEvent, uint uElapse, TimerProc lpTimerFunc );

[DllImport ( "user32", SetLastError = true )]
private static extern bool KillTimer ( IntPtr hWnd, uint nIDEvent );

[DllImport("user32", SetLastError=true)]
private static extern bool GetMessage (out MSG lpMsg, IntPtr hWnd, uint wMsgFilterMin, uint wMsgFilterMax);

[DllImport ( "user32", SetLastError = true )]
private static extern int DispatchMessage ( ref MSG lpMsg );

static void Main ( string[] args )
{
TimerProc lpTimerFunc = TimerFunc;
uint nIDEvent = SetTimer ( IntPtr.Zero, 0, 1500, lpTimerFunc );
if ( nIDEvent != 0 )
{
MSG msg;
while ( !done )
{
GetMessage ( out msg, IntPtr.Zero, 0, 0 );
DispatchMessage ( ref msg );
}

Console.WriteLine ( "Killing Timer" );
Console.WriteLine ( "Kill Result: {0}", KillTimer ( IntPtr.Zero, nIDEvent ) );
Console.ReadLine ();
}
else
{
Win32Exception ex = new Win32Exception ( Marshal.GetLastWin32Error () );
Console.WriteLine ( ex.Message );
}
}

static void TimerFunc ( IntPtr hWnd, uint uMsg, uint idEvent, uint dwTime )
{
Console.WriteLine ( "Tick: {0}", dwTime );
if ( --count == 0 )
done = true;
}
}
}
 
Tom said:
On 2010-02-26 said:
Sure you do. You are allowed to pass NULL for the hWnd parameter, but
you still have to have a window somewhere, and you still need to be
dispatching messages for the window.
[...]

Actually Peter - you don't need to have a window handle or a window to use
SetTimer. What you need to do is dispatch messages on the callign thread...

Hmmm…been doing too much Forms programming, where you practically never
are dispatching messages without a window. As you can see above, at
least I got the dispatching part right. :)

Thanks for the correction.

That said, I still don't understand what it is the OP wants that he
thinks doesn't exist in .NET.

Pete
 
Tom said:
On 2010-02-26 said:
Sure you do. You are allowed to pass NULL for the hWnd parameter, but
you still have to have a window somewhere, and you still need to be
dispatching messages for the window.
[...]

Actually Peter - you don't need to have a window handle or a window to use
SetTimer. What you need to do is dispatch messages on the callign thread...

Hmmm?been doing too much Forms programming, where you practically never
are dispatching messages without a window. As you can see above, at
least I got the dispatching part right. :)

Thanks for the correction.

That said, I still don't understand what it is the OP wants that he
thinks doesn't exist in .NET.

lol.. to be honest, i don't either. From what I've seen, he was describing
some common hacks used to get asyncronous callbacks working - none of which
are needed in .net...
 
Back
Top