In earlier versions, this was the only way to handle callback. Now, it is only a small part of the callback system.
Just like you would poll your events from sfml, you can poll your callbacks from tgui.
Widgets don’t send callback by default, you have to ask them first. This can be achieved by using one of the bindCallback functions. When you just poll the callback from the gui, then you only need to pass a trigger.
But sometimes you don’t want to poll the callback, you want a function to be called when something happens. Here, ‘function’ can be a normal function, a lambda expressing or a static member function.
But what about non-static member functions? No problem, but you’ll have to pass an extra parameter.
Until now, the functions did not have any parameters. But you can technically use any function to which you have bound parameters.
If you have a simple function that is called when the button is pressed then you don’t have to care about this, but in many situations you will need to figure out where the callback came from.
If you are polling the callback the the only thing to do is give every widget a unique id.
So when you are in the pollEvent loop you can just check callback.id to find out if it was the button who send the callback. The callback.trigger might also be usefull to find out what triggered the callback (left mouse click or key press or something else).
But how do you access this information when you aren’t polling? You have a function and you want to know more about the callback that was send. You will have to give your function an extra parameter.
Now you can access all information in the function that can be found in the Callback struct. There is however one small catch. If you add this parameter then you can no longer use the normal bindCallback function. Instead, you must use the bindCallbackEx function. It is exactly the same, but it tells the compiler that the function has this extra parameter.