Event handling + merging of with Poco C++

Coming from AS3 and Obj-C / Cocoa i find events invaluable, are there any plans to implemt some kind of event handling in of? I.e some kind of observer pattern implementation such as notifiers/delegates, signals/slots, dispatchers/responders etc…?

After a lot of research on various general purpose libraries I’ve started to merge of with the poco c++ library, primarily to get access to a flexible event system. So far I’ve only used it for a week or so, and not used much more than the event and time classes, but those alone was worth the effort of including it. It was a little tricky to get going in xcode since there’s no pre built framework or xcode tutorial… But otherwise it’s very well documented and structured, and it feels very solid.

Now that I’ve started to work with Poco C++ I’m thinking that wrapping it for of or (even better) include it at the core would be nice. It would give of users access to a lot of goodies (see the list below) and unleash a lot of power that people could build addons on top of. I would for example gladly release my arduino, tweener/caller and dmx libraries (which all make use of poco)… Including it doesn’t mean that you have to expose it, you could still build of classes on top of it, but it would be there for people who want to dig deeper…

Anyway, even if you don’t go for poco I think a flexible event system would be valuable in of…

here’s poco


and here’s a cut’n’pasted list of some of its features

# threads, thread synchronization and advanced abstractions for multithreaded programming
# streams and filesystem access
# shared libraries and class loading
# powerful logging and error reporting
# security
# network programming (TCP/IP sockets, HTTP, FTP, SMTP, etc.)
# XML parsing (SAX2 and DOM) and generation
# configuration file and options handling
# database access

hey - yeah I a while back I was looking at poco.
The features are impressive but it is quite a huge library.
I don’t think I ever got it working with openFrameworks so I would love to check out an example xcode project if I remember correctly its broken up into different functionality and you can just import the stuff you want like events or xml.

Anyway I would be curious to check it out.
I think adding it at core would be way too much bloat but it would be nice to see what stuff we could use.

Also what sort of event stuff are you after? Can you give an example?

I am curious too – since it does a bunch of things that seem useful … it’d be interesting to experiment with –

for signals, I thought I would mention these:


both look really simple, and worth hooking up / evaluating…


Hey, sorry for the slow reply…

By adding Poco to the OF core I mean adding it as a framework, like QT, OpenGL, GLUT etc and making the openFrameworks lib dependant on it so that it’s guaranteed to be there for addons to use…

I guess that that bloats OF a bit, but not much more than the existing libraries and frameworks do. If you want all parts of of to be easily understandable then it’s perhaps not the thing to do. If you want of to provide easy to use layers on top of more complicated code then I think it’s ok. OpenCV is for example pretty intense if you dig into it, but as an OF addon you can achieve things with it without digging that deep… To mee that’s the beuty of OF. I don’t care much about the internals of libraries such as poco or openCV or QT as long as they work.

Poco is pretty huge, the compiled library and header files are around 30mb, but it is, as you said, broken up in different functionality . The foundation is still 10mb though so even if you only include that it would make OF a much heavier download. I don’t know if that’s an issue though (it’s not for me)…

Poco is cross platform, but compiling it and distribute it for all platforms would mean some work, so I understand if you are skeptical… it’s always a risk to rely on 3d party code, but poco looks so fresh (in the c++ world) that I think it’s worth investigating further…

With events I’m looking for something similar to how they work in AS3. I basically want object A to be able to say “hey, I did something, here’s the result” and object B and C to register to receive a notification and the result. Without A knowing about B and C.

I do for example have a class that communicates with an arduino board and triggers events when a digital pin on the arduino changes value. This is how it works with Poco:

In testApp I say that I want to listen to events from my arduino instance (called arduino) like this:

arduino.EDigitalPinChanged += Delegate<testApp, int>(this, &testApp::onPinChanged);

when the arduno instance detects a change on a pin then it will trigger the EDigitalPinChanged event and as a result the onPinChanged function (below) will be executed in testApp, with a pointer to the arduino object that triggered the event and the pin that changed as parameters:

void testApp::onPinChanged(const void* pSender, int thePin){


if I want to stop listening for events from arduino then I just do like this:

arduino.EDigitalPinChanged -= Delegate<testApp, int>(this, &testApp::onPinChanged);

I can swap the function in testApp that will pick upp the event like this (overwriting the old one):

arduino.EDigitalPinChanged += Delegate<testApp, int>(this, &testApp::onPinChangedTwo);

My arduino object does not care how many, if any, objects that are listening to it’s events or the names of functions that takes care of the events… It simply triggers and event like this:

EDigitalPinChanged.notify(this, thePin);

in the Arduino.h file I’ve declared the event object like this:
Poco::BasicEvent EDigitalPinChanged;

Apart from this I only have to include the necessary Poco classes in arduino and testApp…

I haven’t tried libsigc but I started out using sigslot for events, it worked well, though I like the poco syntax better. It also seems like it’s not actively developed any more, I’m not sure how dated it is… Including poco just for events is a bit overkill, then I would go for something like sigslot. But poco has a lot more to offer i think…

Is your code open source as well? I’ll be really happy to see how are you implementing this.

Tnx, F.

hi erik

just a heads up that we are definitely going to consider adding poco to the core, but likely not this next release since we are almost done and this is a bit of an undertaking - we did consider it at some earlier point, but it was a bit too massive to consider. now, looking at all the addons we’ve built (network, thread, xml, etc) it seems pretty clear that we’d gain alot from an underlying platform as opposed to mixing “best-of” libs, but I like to get some real worl experience with a library first to see how easy it is to solve certain problems, etc before committing.

I’m having some issues out the gate compiling it outside of VS (since we will need to compile it on dev-cpp, vs, and codewarrior…), but I am used to compiling issues, so i will attack it a bit when I have free time. I’m not frightened when I see thousand of errors :slight_smile:

if you learn something interesting, please keep us posted. any examples or ideas are helpful.

take care!!

zach: that’s great! I hope you get it to compile without to much trouble, I’m really interested in hearing your thoughts on it as well… I’d especially like to try some of the Net stuff, but I don’t have an immediate use for it so I’ll have to stick to the event and time classes for a while. btw, I get the impression that they are working on unified serial/parallel and usb i/o for 1.4 which sounds interesting…

Here’s the build / link procedure I ended up with for Xcode on Leopard. I haven’t worked with VS but maybe there are some similarities… It would be a lot easier (in Xcode) if there was a universal framework. I’ve never made one myself but I’m going to bring up the subject on the poco forum.

paramendil: I don’t have time to document, package and support my code right now, and it’s a bit to complex to just throw out there since it requires a proper poco setup, but I intend to make it open source eventually… I’ll keep you posted on any progress…

// e

Compiling POCO as a static library (Intel and Leopard)

Download and unpack the POCO Economy Edition tar.bz2 tarball (the scripts in the zip and gz tarballs uses DOS/Windows end-of-line charachter and not UNIX end-of-line characters so they won’t work).

Open …/poco-1.3.2/build/config/Darwin in a text editor and change the line LINKMODE = SHARED to LINKMODE = STATIC.

Open a terminal window in …/poco-1.3.2/ and type

./configure --configuration=Darwin

then build the library by typing “make”

Linking the compiled library in Xcode (Intel and Leopard)

Make a new a folder called poco and inside this folder make the folders: include/Poco and lib. You should now have the following folder structure:


Copy all of the .h files in …/poco-1.3.2/Foundation/include/Poco to …/poco/include/Poco.
Copy the following folders to …/poco/include/Poco


Copy all of the .a files in …/poco-1.3.2/lib/Darwin/i386 to …/poco/lib.

You should now have the following folder structure:
…/poco/include/Poco (with .h files)
…/poco/include/Poco/DOM (with .h files)
…/poco/include/Poco/Net (with .h files)
…/poco/include/Poco/SAX (with .h files)
…/poco/include/Poco/Util (with .h files)
…/poco/include/Poco/XML (with .h files)
…/poco/lib (with .a files)

Open your Xcode project and go to the Build tab in “Project->Edit Active Target”

Remove ppc from “Architectures” (leaving only i386)

Add …/poco/include to the “Header Search Paths” (replace … with the full path to your poco folder)

Go to the General tab in “Project->Edit Project Settings” and change “Cross-Develop Using Target SDK” to Mac OS X 10.5.

Create a new group called poco inside “libs/other libs” in “Groups and Files”
From the finder drag all the .a files in …/poco/lib folder to your poco group (choose relative to project as the reference type).


thanks for posting this info

vstudio compiles fine and easily, as expected the others are a bit trickier. codewarrior I’m down to about 120 errors (now down to 12…–> now 3 :slight_smile: )-- it was tons of errors at first, but it’s coded pretty well and I was able to solve alot of issues by compiling all the c libraries first (ie, zlib, pcre, etc)… if codewarrior works then devcpp wont be too hard.

when I get it I’ll post it on the poco forum, there are some changes I am making (for example, poco/types.h) that could be useful to support non msvc compilers.

take care!

ok - I got it compiled in CW finally – some small changes was needed, not massive.

it’s pretty huge :slight_smile: – my static foundation lib is about 20mb… will check it out over the next few days and see how it runs.

take care,

hey, any progress with poco yet?

I’ve put up some experimental code at http://code.google.com/p/cppglue/

It’s not that portable in its current state, but some classes, such as Tween.cpp, might be interesting for you to look at since they use poco events and timestamps…


hi erik

cool ! nice to see that progress

we’ve gotten poco up and running enough to show that it would be good to have. it wont be in 0.05 but it’s next on our list of major changes (and it will be really helpful for addons). it’s too much work for now to bring it in (since the addons are taking most of your energy), but we have looked at it carefully and we’re happy to try adding it to the core. please keep us posted on your progress, and we’ll keep plugging away and keep you up to date on where we’re at.

thanks for suggesting it !!

  • zach

Glad to hear that! I’ve now used the logging, XML parser/writer and FTP functionality as well as some smaller but amazingly useful classes like the Stopwatch. Everything performs really well, and once you’ve worked a bit with it it’s all quite straight forward to use (at least for being c++)… This is for example the amount of code that’s needed to connect to an ftp and upload a file (only poco and std):

void LogController::uploadFile(string file){
string remotePath = “/”;
_ftpClient = new FTPClientSession(_ftpHost, 21);
_ftpClient->login(_ftpLogin, _ftpPassword);
std::ostream& ftpOStream=_ftpClient->beginUpload(remotePath+file);
std::ifstream localIFStream((_logPath+file).c_str(), ifstream::in);
StreamCopier::copyStream(localIFStream, ftpOStream);
delete _ftpClient;
catch (Exception& exc)
cout << exc.displayText() << endl;

the code is ripped out of context, just wanted to show that it wouldn’t require much wrapping to become super easy to use ftp addon like

ofFTP.login(string host, int port, string login, string password)
ofFTP.uploadFile(string localFile, string remoteFile)
ofFTP.downloadFile(string localFile, string remoteFile)

haven’t had time to look into the multi threading stuff yet but it looks promising so it could probably be made to run asynchronously and dispatch events on login and file transfers without too much more work…

it makes a lot of tedious stuff easy and lets you focus on the fun parts, so, yeah, keep plugging it :slight_smile: do understand if you’re busy enough at the moment though…

// e

Thanks so much for this! I just got Poco working and I’m loving it already. This is going to make my life so much easier.

3 things:

  1. I am running on 10.4 – I didn’t have to do the Linking, step 4 and it still works
  2. After compiling, the only thing in poco-1.3.2/Net/include/Poco was the ‘Net’, folder. The ‘DOM’, ‘SAX’, and ‘XML’ folders were in poco-1.3.2/XML/include/Poco
  3. There are great examples in poco-1.3.2/[Whatever lib]/samples

I am very excited about using this library. I haven’t tried out the XML stuff yet, but everything is so straightforward and well documented that I bet it is going to be great.

cool! The dom/sax/xml folders should be where you found them, that was a typo, don’t know how to go back and edit the post…

Another thing I found is that if I drag all the .a files in step 5 then I get compilation errors when including some poco classes (can’t remember which). I remedied this by only using the .a files that doesn’t end with d before the .a extension. So step 5 should be:

Create a new group called poco inside “libs/other libs” in “Groups and Files”
From the finder drag the .a files in the …/poco/lib folder that doesn’t have a d before the .a extension (i.e libPocoNet.a and not libPocoNetd.a) to your poco group (choose relative to project as the reference type).

wonder if the “d” libs are not compiled for debug mode, thus useful if you need to compile OF in debug? worth taking a look at – seeing if your OF project will compile OK in debug / and if you could add those “D” libs for the debug release. We do this w/ rtAudio on visual studio (alternate between debug and release versions of the libs). it’s not always the easiest (that presents some challenges) but it’s useful in case there is a problem in libpoco – the debugger will be able to say what is the offending line, etc… anyway, just a thought.

I’m glad to hear more positive feedback about poco – we’re pretty excited about it.

take care,

I compiled poco on my intel 10.4 machine and uploaded to http://openframeworks.cc/files/poco/poc-…–xcode.zip

I made an install.txt and also included the following examples. They’re straight from the Poco folder (not OF-ized), but I think they are pretty straight forward, and super helpful.


zach: yup, you’re right, the XXXd.a files are for debuging…

I decided to give it a go making a universal (ppc and intel) poco library that links against the 10.4u sdk (so its good for tiger and leopard users)


I included instructions on how to build the ppc and the intel libraries separately and then use lipo to join them together to make the libs universal binaries. Based on the instructions by erik and jeff.

There is a #define conflict with ofNetwork which we will sort out for 005 - but apart from that it builds and runs fine. Being able to easily download an image via a url and load it into an ofImage object is awesome! I quickly tried sending an email from openFrameworks but I think I had my postfix (smtp server) incorrectly setup.


Getting poco to work in linux was pretty easy. In Ubuntu, I installed libpoco2, libpoco-dev, and libpoco-doc with apt-get. In my make file, I added -I/usr/include/Poco to the CXXFlags and -lPocoFoundation -lPocoNet (or whatever poco libraries you need to link) to LDFLAGS. In the code, I included the libraries like in their samples: #include “Poco/Net/HTTPRequest.h”

Theo, when you downloaded the image w/ poco and loaded it into ofImage, did you do it by saving it to a file first? Is it possible to load ofImage (or the underlying FreeImage object) from an input stream or whatever you can get back from a poco HTTP request?


Hey glad to hear!

For loading an image into ofImage I just added an ofstream (not openframeworks) object to reference the file. Then I give the ofstream to poco and it does the rest :smiley:

	//some poco stuff  
	//specify out url and open stream  
	URI uri("[http://www.coolhunting.com/images/funky2.jpg");		](http://www.coolhunting.com/images/funky2.jpg");		)  
	std::auto_ptr<std::istream> pStr(URIStreamOpener::defaultOpener().open(uri));  
	//create a file to save the stream to  
	ofstream myfile;		  
	//copy stream to file  
	StreamCopier::copyStream(*pStr.get(), myfile);  
	//load into an ofImage!