There's on built in way to do this right now because it is very easy for such a function to tank 4coder performance. Right now it is event driven so if you leave it sit for an hour it's CPU usage stays at 0. With a tick function, even if you don't do anything in your tick, 4coder has no way of knowing that your tick won't do anything big and so it is forced to do a full update as if something is going to happen, which is why I originally decided against a time type system.
However, this request has come up frequently enough that I am considering adding it and letting you manage the performance consequences yourself. In the mean time, I and another person who requested this have found a work around that makes it possible for you to whip up your own time events anyway, but you'll have to do some platform specific work to set it up:
1. Write a thread that will send your tick events:
2. Decide what key you will allocate for tick events, F16 is a good candidate, especially if your keyboard doesn't have that key. On windows this means:
3. Put your tick event in a custom command:
4. Bind your tick to the F16 key at the global level in the bindings:
5. Launch your thread in the startup hook.
It's obviously more plumbing than you'd like to have to do, and if you ever want different flavors of times/ticks this would all fall apart, but hopefully it's a good enough stop gap measure for you until I do an upgrade to the event handling API and add some timer abilities there.
However, this request has come up frequently enough that I am considering adding it and letting you manage the performance consequences yourself. In the mean time, I and another person who requested this have found a work around that makes it possible for you to whip up your own time events anyway, but you'll have to do some platform specific work to set it up:
1. Write a thread that will send your tick events:
1 2 3 4 5 6 | void tick_function(void *){
for (;;){
Sleep(10*1000); // Spread out my ticks to every 10 seconds
/SEND_EVENT_TO_MY_MAIN_THREAD/
}
}
|
2. Decide what key you will allocate for tick events, F16 is a good candidate, especially if your keyboard doesn't have that key. On windows this means:
1 2 3 4 5 6 7 8 9 | void tick_function(void *){
for (;;){
Sleep(10*1000); // Spread out my ticks to every 10 seconds
INPUT in = {0};
in.type = INPUT_KEYBOARD;
in. DUMMYUNIONNAME.ki = VK_F16;
SendInput(1, &in, sizeof(in));
}
}
|
3. Put your tick event in a custom command:
1 2 3 | CUSTOM_COMMAND_SIG(tick){
// whatever it is we want to do regularly
}
|
4. Bind your tick to the F16 key at the global level in the bindings:
1 | bind(context, key_f16, MDFR_NONE, tick); |
5. Launch your thread in the startup hook.
It's obviously more plumbing than you'd like to have to do, and if you ever want different flavors of times/ticks this would all fall apart, but hopefully it's a good enough stop gap measure for you until I do an upgrade to the event handling API and add some timer abilities there.
When talking about timeouts one common operation comes to mind: delayed autosave
You don't want to save at every keystroke but instead want a short delay after the first keystroke that gets extended on each keystroke and a max delay that won't get extended (to ensure some autosaving does happen). This requires one-shot timers.
The next possibility is a library that requires polling or one that doesn't expose an OS native handle that can be waited on and its own wait function doesn't play nice with threads.
You don't want to save at every keystroke but instead want a short delay after the first keystroke that gets extended on each keystroke and a max delay that won't get extended (to ensure some autosaving does happen). This requires one-shot timers.
The next possibility is a library that requires polling or one that doesn't expose an OS native handle that can be waited on and its own wait function doesn't play nice with threads.
Mr4thDimention
Right now it is event driven so if you leave it sit for an hour it's CPU usage stays at 0. With a tick function, even if you don't do anything in your tick, 4coder has no way of knowing that your tick won't do anything big and so it is forced to do a full update as if something is going to happen, which is why I originally decided against a time type system.
However, this request has come up frequently enough that I am considering adding it and letting you manage the performance consequences yourself.
It's obviously more plumbing than you'd like to have to do, and if you ever want different flavors of times/ticks this would all fall apart, but hopefully it's a good enough stop gap measure for you until I do an upgrade to the event handling API and add some timer abilities there.
An API like this would be nice (?):
1 2 3 4 5 6 7 | CUSTOM_COMMAND_SIG(tick){
// whatever it is we want to do regularly
// don't do a full update unless I explicitly request it from my callback
please_do_a_full_update();
}
// request 4coder to spawn a thread that calls my callback tick every 10 seconds
give_me_ticks(tick, 10*1000);
|
So by default 4coder works the way it does now but the user can ask it to have tick threads responsible for firing off custom callbacks. I don't know what a "full update" entails in 4coder but I imagine you could work under the assumption that it doesn't need to be done unless the user explicitly requests it in the callback. No idea if this suggestion is reasonable at all though :)
Though you are going to want a way to stop the ticks (and stop a not yet triggered timeout)
This means giving a handle to the client code so you can refer to a specific set of ticks (or timeout).
This means giving a handle to the client code so you can refer to a specific set of ticks (or timeout).