TimerTask Executor

[ImmuneOne]

Do with it whatever you want. Feel free to ask any question(s).

[.Kinshi]

Sexy dude!

[pro4never]

Nice work ^^

Doubt very many people will end up using it but it's very cool. We've been experimenting with similar concepts on hellmouth although we've currently switched to what is essentially managed timers. It works fantastically so far.

[F i n c h i]

Good job, I really needed it.

[ImmuneOne]

Originally Posted by alexalx

Good job, I really needed it.

Even though thinking it's a good job. May I ask for what and why you needed this?

[_Emme_]

Looking neat bro. For those who wants to keep things cleaner, for the initializing part.

Instead of

TimerTaskExecutor executor = new TimerTaskExecutor();

TimerTask task = new TimerTask(execute);
task.setWaitTime(2000);
executor.ExecuteTimerTask(task);

You could simply just:

new TimerTaskExecutor().ExecuteTimerTask(new TimerTask(execute) { sleepTime = 2000 });

+TimerTask.cs:

public int sleepTime { get { return _waitTime; } set { _waitTime = value; } }

Keep it up bro!

[ImmuneOne]

Originally Posted by EmmeTheCoder

Looking neat bro. For those who wants to keep things cleaner, for the initializing part.

Instead of

TimerTaskExecutor executor = new TimerTaskExecutor();

TimerTask task = new TimerTask(execute);
task.setWaitTime(2000);
executor.ExecuteTimerTask(task);

You could simply just:

new TimerTaskExecutor().ExecuteTimerTask(new TimerTask(execute) { sleepTime = 2000 });

+TimerTask.cs:

public int sleepTime { get { return _waitTime; } set { _waitTime = value; } }

Keep it up bro!

Wouldn't make a difference you're still creating new instances. Besides, the wait times aren't ment to be changed after being set.. so yeah.

[_Emme_]

Originally Posted by ImmuneOne

Wouldn't make a difference you're still creating new instances. Besides, the wait times aren't ment to be changed after being set.. so yeah.

Yeah, ofcourse, but what I was aiming for was if you're going to have a set of threads/timers (possibly not for CO, but for other applications as this is not CO related really), it'd be easier to manage and organize the initialization the way I suggested - both works the same just saves a couple of rows.

[_DreadNought_]

Looks, In my eyes, Interesting.

I like the idea of TimerTask however much I think

            TimerTaskExecutor executor = new TimerTaskExecutor();

            TimerTask task = new TimerTask(execute);
            task.setWaitTime(2000);
            executor.ExecuteTimerTask(task);

Is quite a handful.

I notice that the DateTime function is used alot too, Wouldnt it be better to use the TIME function? aka time32 which I believe is a native C++ function.

And would you like to explain why do all of what your doing when

new Thread(Core).Start();

void Core()
{
if (LastCheck.AddMili <= CurrentTime)
{
LastCheck = CurrentTime;
blabla
}

Seems smaller and easier.

However, I've tested this minorly(<-- not a word o.o) and it does appear to work and do its job with minimal resources.

Nice work, If my threading system doesnt work out its very nice to know I've got something to fall back on. +K
}

[ImmuneOne]

Originally Posted by EmmeTheCoder

Yeah, ofcourse, but what I was aiming for was if you're going to have a set of threads/timers (possibly not for CO, but for other applications as this is not CO related really), it'd be easier to manage and organize the initialization the way I suggested - both works the same just saves a couple of rows.

Who said it is co related? However, you could easily implement this into a co environment.

            TimerTask staminaTask = new TimerTask(client, execute);
            staminaTask.setWaitTime(2000);
            executor.ExecuteTimerTask(staminaTask);

        static bool execute(object targObj, DateTime timeofExecution)
        {
            //update stamina perhaps?
            Console.WriteLine("Executed!");
            return true;
        }

[_Emme_]

Originally Posted by ImmuneOne

Who said it is co related?

It's in the CO section darling

Anyhow, yes, and that's what makes these kind of codes beautiful, they can be implemented onto any project

[_DreadNought_]

Originally Posted by ImmuneOne

Who said it is co related? However, you could easily implement this into a co environment.

            TimerTask staminaTask = new TimerTask(client, execute);
            staminaTask.setWaitTime(2000);
            executor.ExecuteTimerTask(staminaTask);

        static bool execute(object targObj, DateTime timeofExecution)
        {
            //update stamina perhaps?
            Console.WriteLine("Executed!");
            return true;
        }

Was meant to ask, Why make "client" an object when a foreach loop is just as easy.

[ImmuneOne]

Originally Posted by _DreadNought_

Was meant to ask, Why make "client" an object when a foreach loop is just as easy.

You'd have to compare lastStamina.AddSeconds(2) and DateTime.Now with every single object.

[_DreadNought_]

Why not make it generic, not dynamic?

[ImmuneOne]

Originally Posted by _DreadNought_

Why not eat chocolate pie, not apple pie?

Because apple pie is actually more delicious than chocolate pie.