Where are the event callbacks?

[mnbayazit]

Hi,

I'm reading the window-events tutorial and it says here that we can use callback functions. So how exactly do we register an event callback?

[Laurent]

You misunderstood, this is just a general description that introduces the 2 usual ways of catching events. The paragraph right below explains what SFML uses (which is polling, not callbacks).

[mnbayazit]

Oh... well that makes it a little awkward to decouple event handling from the main loop :\

[Jaenis]

Actually decoupling is very simple, with boost signals.


First declare event signals global (or better yet, have a event handler class that does this)

Code: [Select]

boost::signals2::signal<void (const sf::Event &)> EventSignals[ 16 ]; (See note on bottom)


Then hook your functions into signals:

Code: [Select]


// Connect sf::Event::Close event to CloseEvent function
EventSignals[ sf::Event::Closed ].connect( CloseEvent );

// Callback function
void CloseEvent(const sf::Event &Event)
{
// Do something
}


And in mainloop have this event processing code:

Code: [Select]

// Process events
sf::Event Event;
while (App.GetEvent(Event))
// Call all connected functions
EventSignals[ Event.Type ]( Event );


Or with classes:

Code: [Select]


class Foo
{
// Constructor
Foo();

// Key event handler, has to be static
// (one should be able to use boost::function too, haven't checked that yet)
static void KeyEvent(const sf::Event &Event);
};

// Constructor
void Foo::Foo()
{
// Connect KeyPressed event to Foo::KeyEvent function
EventSignals[ sf::Event::KeyPressed ].connect( Foo::KeyEvent );
}

// This function will get called when key is pressed
void Foo::KeyEvent(const sf::Event &Event)
{
if (Event.Key.Code==sf::Key::Escape)
EscPressed=true;
}



Note:
Laurent, could we get "sf::Event::Count" variable to get number of event enums?
Pretty please?  :roll:

[Laurent]

Laurent, could we get "sf::Event::Count" variable to get number of event enums?

Well, I think you shouldn't need this
You code is simple and short, but it doesn't have the best design in my opinion. If you're using a separate callback fore every event then you should pass it the proper parameters, not the full sf::Event. Then you wouldn't store the callbacks in an array, and you would no longer need sf::Event::Count.

Code: [Select]

struct EventHandler
{
    signal<void ()> OnClose;
    signal<void (sf::Event::KeyEvent)> OnKeyPress;
// or
    signal<void (sf::Key::Code, bool, bool, bool)> OnKeyPress;
};

[Jaenis]

Laurent, could we get "sf::Event::Count" variable to get number of event enums?

Well, I think you shouldn't need this
You code is simple and short, but it doesn't have the best design in my opinion. If you're using a separate callback fore every event then you should pass it the proper parameters, not the full sf::Event.

Why shouldn't I use the full sf::Event? It is union anyhow, which is great for this kind of thing.
If I explode that code to handle all events separately, it gets quite long. And I don't see any point in it

Also, if/when SFML will add more events I'll have to modify that code if I am passing the actual parameters. But if I am just passing that sf::Event, then I don't need to do anything to get it work.

[Laurent]

Why shouldn't I use the full sf::Event? It is union anyhow, which is great for this kind of thing.
If I explode that code to handle all events separately, it gets quite long. And I don't see any point in it

The point is that users won't receive 90% of undefined/useless data in their callbacks. Have you seen on this forum the number of people who retrieve the key code after a mouse move event (for example)?

When my callback is called I expect to get the proper parameters, not a general-purpose union in which I have to manually choose the member corresponding to the type of event. That makes no sense and brings more confusion.

If I explode that code to handle all events separately, it gets quite long

Which is good if it makes the public API easier/cleaner.

Also, if/when SFML will add more events I'll have to modify that code if I am passing the actual parameters. But if I am just passing that sf::Event, then I don't need to do anything to get it work.

Hey, why don't you use a void* parameter? This way you won't have to update your code, even if SFML switches to something else than sf::Event

[Jaenis]

Have you seen on this forum the number of people who retrieve the key code after a mouse move event (for example)?

Ahaa, you are thinking this from general usage perspective.
I instead thought this from my usage perspective, where when I have "KeyHandler" function, I'am supposed to access the key data and ignore other union members.

To get rid of this thing you pointed above, change that event structure from unions to inheritance. Then when user gets keypress event, he has to downcast it to proper class.
Though this would be more complicated to use because of dynamic_casts :lol:


But anyhow, just adding that "event count" would allow both ways

Hey, why don't you use a void* parameter? This way you won't have to update your code, even if SFML switches to something else than sf::Event :wink:

 :shock:
Scary  

[Laurent]

Ok, you won...