running a piece of code once, ofEvents, c++ question.

Hi y’all!
I know setup() runs in the beggining of the program, update() as fast as it can, and draw() every time it has to draw on screen, but I’m intrigued by the keyPressed(), keyReleased() and such.

Lets say that everytime someone hits the letter “a” I want a transition to happen once and only once (like a fade in-fade out). The computer knows now to trigger a sequence for the transition but it can only happen once. In pseudocode, how can an event that lasts a certain amount of time be triggered without the event being instantaneous (fade in and out versus the instantaneous key press).

What are keyPressed() type event called in c++ (events that happen only once).
Are these what ofEvents are used for?
What is a “listener” used for in these cases?
Are Events and Listeners commonly used in c++?
Is the customEventExample (v0071) a generic example of usage of events in c++?

I’m not trying to avoid google searching this but I think I’m missing the very basics of purpose of Events in general.

Any guidance will of course be welcome. Thank you. =D

Have you already taken a look at the documentation on the of homepage? There’s a nice presentation about events by roxlu at

Yes, but I think it is time to reread them then.

Some things that I still don’t get:
is this something common in c++ use?
in this particular topic, does openF simplify a far more complicated system?
What is the need for the Poco Events system?

Thank you!

x) yes, (if you mean events), as far as i know.
x) i guess so
x) don’t know.

I wonder what you want to learn from the answers to these questions?

I like to tinker, modify stuff and learn more about how it internally works. So far I’ve been able to, for example, start using openGL without using the functions that openFrameworks provides. However, “events” and such have confused me a bit since I’ve seen them used in collision detection in Box2D (not ofxBox2d) and stuff like that.

In short, just to get a better understanding of how things work. =D

hey Irregular,

events are one of C++'s weaker points as a language. basically there is no easy way to handle events in C??, and any C++ code syntax that is used to implement an event system just ends up being a big mess, regardless of how well it is designed.

for the same reason there aren’t really any standard names for the functions that are used to handle events. i guess keyPressed() could be named a ‘callback’, but that’s a pretty generic term that doesn’t mean anything in particular. it could also be named an ‘event handler function’.

ofEvents are a way of firing user-defined events. if i have a process that takes many frames to complete, like the fade in/fade out example you suggested, i can fire an event at the end of this process. other objects can listen for this event, and when they receive it they know that they should do something. one simple alternative is for each other object to maintain its on timer internally which is updated every frame, but this would mean lots of duplicated code and introduces many opportunities for bugs to appear. imagine a case when you have 100 other objects listening: having 100 timers running individually, in addition to the timer in charge of the fade effect, is clearly less reliable than having just the one timer (the fade effect) and an event that is fired.

openFrameworks uses Poco Events because Poco does a lot of the back-end of events. to a certain extent one of the design philosophies behind openFrameworks is to re-use existing code wherever possible: we could have created our own event handling loop but then we’d be responsible for tracking down and fixing any bugs in it, while Poco already provides a mature, bug-free event handling system.

for a brief overview of what a Listener might be, have a look at the Observer/Observable design pattern: . the basic concept is that a ‘listener’ labels an object as being actively interested in a particular event. my app might have hundreds of events firing, but if my class is only a ‘listener’ for one particular event it will ignore all the other invents. (classes can be listeners for multiple events as well, of course.)

events and listeners are commonly used when handling GUI systems, but in general they are a design methodology that allows for decoupling parts of your application. suppose i have an app that uses a Kinect to detect a hand-wave gesture. by using events i can have the same hand-wave gesture detection code working in 3 different applications, one to trigger a sound, one to trigger a visual response like an animation, and one to trigger some data to be uploaded to a web site, without having to modify the hand-wave gesture detection code. if i was not using events i would need to modify the hand-wave gesture detection code each time to call the right method on the right class in each application.

the reason why keyPressed and keyReleased run as they are probably has a lot to do with the fact that this is how GLUT handles keyboard events, and in its early version openFrameworks was very much tied to GLUT. there are other ways of handling a keyboard input system, depending on exactly what you want to achieve. for example, one way is to have a buffer (a fixed location in memory) that is appended to every time a key is pressed. another way is to have an array of booleans, one for each key on the keyboard, each of which is either true or false depending on whether the key is currently pressed or not (this is how you can detect multiple simultaneous key inputs). this last way is actually how a keyboard works at the hardware level: it’s just an array of switches. there is a lot of fancy programming between the keyboard hardware and your application to allow a function to be called when a key is pressed, and another function to be called when the key is released – it’s generally the case, although not always, that this is the most convenient way of handling keyboard input.

hope this helps!


1 Like

Couldn’t have wished for a better and more thorough explanation on exactly what I wanted to know. Now I can go deeper into the topic.
Thank you damian!

Damian, great infos! that post would be great to have in some form in the documentation/tutorials section on the homepage, don’t you think?

I second this!
If I ever have such clear knowledge of any subject openF related I’d make a tutorial. =D