understanding of event system for hooking external input lib

[Demone]

I need to hook an external Input library. (wich provide much more features, multiple mouses and keyboards for example)
Let me try to explain what I need to achieve and to understand few things that I'm missing about SFML.

1) I don't understand this piece of code:

Code: [Select]

void WindowImplWin32::processEvents()
{
    // We update the window only if we own it
    if (!myCallback)
    {
        MSG Message;
        while (PeekMessage(&Message, NULL, 0, 0, PM_REMOVE))
        {
            TranslateMessage(&Message);
            DispatchMessage(&Message);
        }
    }
}

doesn't "globalOnEvent" already process events?


2) The library (cross platform library) I want to use needs to be used like that:

example:

Code: [Select]


        MSG Message;
        while (PeekMessage(&Message, NULL, 0, 0, PM_REMOVE))
        {
            TranslateMessage(&Message);
            DispatchMessage(&Message);
        }

///the following piece of code will be ideally added to "processEvents"
//cross platform stuff of the library
if( keyboard )
{
keyboard ->capture(); //capture the event
if( !keyboard ->buffered() )
handleUnBufferedKeys();
}


the problem is that I don't know how changin the "processEvents" method will affect SFML event system.

3)For example what about resizing/closing events? They will get lost?

4)How can I stop SFML from generating MOUSE/KEYBOARD/JOYSTICK events in order to use events from external library?

[Laurent]

Why do you need to care about how SFML handles events internally? Can't you just ignore SFML events and use your library directly in your code?

1) I don't understand this piece of code
[...]
doesn't "globalOnEvent" already process events?

This is how event handling works with the Windows API. GlobalOnEvent will be called by DispatchMessage.

the problem is that I don't know how changin the "processEvents" method will affect SFML event system.

3)For example what about resizing/closing events? They will get lost?

It depends how your library works. But it should be ok.

4)How can I stop SFML from generating MOUSE/KEYBOARD/JOYSTICK events in order to use events from external library?

You can't. But, again, why can't you simply ignore them?

[Demone]

Why do you need to care about how SFML handles events internally? Can't you just ignore SFML events and use your library directly in your code?

so

Code: [Select]


while(myWindow->isOpened())
{
    keyboard->capture();

//other SFML & openGL stuff
}


?

I think that in such case:
1) the events are not received since already dispatched by SFML
2) memory leach, the internal event queue continue to grow.

[Laurent]

Yeah, you must still call GetEvent.

But how does your library works? Is it initialized with the window handle and uses events, or does it request the state of the keyboard/mouse/joystick devices without using window events at all?

[Demone]

the library still get events from window.. So it needs a window handle, but is not able to create a window handle (i'm using SFML also for all network, threading, and rendering features, not only for window handles)..

So I need to stop SFML processing events, but not all events (resizing and closing the window for example are in my interest that are processed by SFML). I tried modifing the code in few places but didn't worked for now. I'm trying to understand better the design of SFML, if I know how internally handles events probably i'll be able to modify the code where needed.

[Laurent]

So I need to stop SFML processing events

Why? Your library should be able to work even if SFML continues to process events on its side.

[Demone]

Why? Your library should be able to work even if SFML continues to process events on its side.

That's the problem, unless i'm going to use some "keylogger" library. There will never be a library able to do that. When SFML processes an event it is LOST forever no one can retrieve it. How can I retrieve a lost event?  

by contrast is SFML that should provide systems for working with other input libraries in my opinion.

Most media frameworks (aka graphics engines) provides a hook for external event/input libraries. I'm guessing why SFML not.

Anyway i'm not asking for a design change of SFML, but just how SFML events works in order that I can safely change its code without having to guess all developers' assumption

(p.s. that's not my library)

[Laurent]

There will never be a library able to do that

SFML does it. If you create a window with the Win32 library, and wrap it with a sf::Window, you can continue to process events on your side, and SFML will be able to see them too.
In fact a good event library should not need anything else than the window handle; all OSes allow windows events to be dispatched to multiple listeners.

But anyway, before telling you how to modify SFML, I need to know which version you use.

[Elgan]

what external events library is it?

[Demone]

sfml is version 1.6

the external library is that one:

http://sourceforge.net/projects/wgois/

all OSes allow windows events to be dispatched to multiple listeners

so you are not referring to the "WindowListener" ? I need just to put the code inside the render loop of SFML? it seems to simple for working for real O_O

[Laurent]

so you are not referring to the "WindowListener" ?

I was not referring to anything, that was just a generic term to say that multiple separate "codes" can listen to events of the same window.

I need just to put the code inside the render loop of SFML?

Which code?

Can you show how you use your library?

[Demone]

Code: [Select]


       
while(mySFMLwindow.Run()
{
        while(mySFMLwindow.GetEvent())
         {  }

        MSG Message;
        while (PeekMessage(&Message, NULL, 0, 0, PM_REMOVE))
        {
            TranslateMessage(&Message);
            DispatchMessage(&Message);
        }

//cross platform stuff of the library
if( keyboard ) //keyborad enabled
{
keyboard ->capture(); //capture the event
if( !keyboard ->buffered() )
handleUnBufferedKeys();
}
     //some rendering
}


[Laurent]

Why did you put a Win32 event loop there? You probably don't need it, since it's already run by SFML.

[Demone]

yes but SFML is eating window events because of PM_REMOVE attribute in PeekMessage. That's what i'm trying to solve ...

[Laurent]

I don't think that your library uses the window's events at all. You don't pass it your window handle, so how could it use its events?

As far as I know, it uses DirectInput on Windows.