Re: GUI clarification

Just to be sure, here an example :

If you managed to feed your MWindow with some events,
you can then handle the button events like this :

1 ) create a static function like this :

void myButtonCallback(MGuiButton * button, MGUI_EVENT_TYPE event)
{
    switch(event)
    {
        case MGUI_EVENT_MOUSE_BUTTON_DOWN:
            printf("button pressed");
        break;
    }
}

2 ) give the callback function pointer to the button :

button->setEventCallback(myButtonCallback);

27

Re: GUI clarification

Yes, this is exactly what I did. But for some reason it doesn't work, while explicitly calling myButtonCallback directly of course does work.
Despite having done setEventCallback(myButtonCallback), debugging with some while(1) loops shows that the button acts like if m_eventCallback is NULL.
Since the MGui code looks correct, my only guess is that, like I wrote before, since we must do

button->setEventCallback(myButtonCallback);

inside the MyGame class, this somehow makes the pointer to the function wrong.
See http://stackoverflow.com/questions/1418 … e-examples for reference and similar topics on the web with these keywords (c++ method class callback etc.).
Still, proposed solutions does not work for me and I'm not even sure this is actually the cause.

Re: GUI clarification

I will be surprised, I use function pointers a lot on all platform.

The problem might be with the MWindow events, or the mouse inputs,
maybe you are using the input context after it's flushed in game update ?

try to test the inputs :

if(input->onKeyDown("MOUSE_BUTTON1"))
    printf("UP");

int mx = input->getAxis("MOUSE_X")*width;
int my = input->getAxis("MOUSE_Y")*height;

printf("mouse : %d %d", mx, my);

you can also try to debug "MWindow::onEvent"
to check if it's called.

If I have time I'll do some tests too.

29

Re: GUI clarification

MGuiButton::onEvent
...
case MWIN_EVENT_MOUSE_BUTTON_DOWN:
        printf("this is reached");
        if(parent->isHighLight() && isMouseInside())
        {
            printf("this is NOT reached");

so the bug it's either in isHighLight() or in isMouseInside()

30

Re: GUI clarification

Actually there are problems with both functions.
Regarding isHighLight(), I guess there are "order" problems: I have a big window completely transparent in which I draw the mouse cursor, but so I can't click the other windows in the background.

Last edited by 255 (2013-10-03 16:19:16)

Re: GUI clarification

ok, so the mouse clic is ok,

parent->isHighLight() and isMouseInside() are both dependent on the mouse motion, the coordinate of the mouse and the window size.

Or the mouse move event is not handle properly, or the mouse position is not correct (needs to be in pixel) or the window size is not defined. Did you specified the pos and size of MWindow as (0,0) for the pos and the screen size in pixel for the size ?

And yes, the order is important, if you clic on the top window, even transparent, only this one will take the event.

32

Re: GUI clarification

anael wrote:

Did you specified the pos and size of MWindow as (0,0) for the pos and the screen size in pixel for the size?

Yes. I didn't do further investigations, I'm stuck on those two functions. Tomorrow I'll see if I can spot the precise bug.

anael wrote:

And yes, the order is important, if you clic on the top window, even transparent, only this one will take the event.

Yes but what is the solution? I have to draw the mouse cursor image on top of everything. To draw an image I need a parent MGuiWindow the size of the entire screen and on top of everything.

Last edited by 255 (2013-10-03 22:08:37)

Re: GUI clarification

about the order, it happen if you have 2 MGuiWindow on top of each other, is it what you have ?

34

Re: GUI clarification

Yes. I'll try to be more clear.
I need to draw:
-some images on the screen (e.g. name of the character)
-some windows on the top (e.g. menu window)
-cursor image
The last point is where the problem arises, since the only solution I found is to draw a big transparent MGuiWindow which in turn draws the mouse cursor image. But this window gets all the inputs, and I can't put it in the background because otherwise you will not see the cursor. Is there a solution for this?

Re: GUI clarification

ok, we can add an option to disable events in a particular MGuiWindow.

something like gwin->ignoreEvents(true);

Re: GUI clarification

added it. Check it out on svn.

37

Re: GUI clarification

The function parent->isHighLight() still blocks the code...

    case MWIN_EVENT_MOUSE_BUTTON_DOWN:
        if(parent->isHighLight()   /* && isMouseInside() */   )

I did

mguiwin_for_cursor->ignoreEvents(true);

Looks like that other than passing events to the next window you also have to highlight it. But this could set the cursor in the background. It's a bit complex. hmm

Last edited by 255 (2013-10-04 16:47:56)

38

Re: GUI clarification

Regarding isMouseInside, instead, I've found the bug.
in MWindow.h

inline void onMove(int x, int y){ m_pos[0] = x; m_pos[1] = y; onEvent(MWIN_EVENT_MOVE); }

should be

inline void onMove(int x, int y){ m_mousePos.x = x; m_mousePos.y = y; onEvent(MWIN_EVENT_MOVE); }

That "m_" is actually misleading.

Last edited by 255 (2013-10-04 17:29:32)

Re: GUI clarification

no it's not a bug, onMove refers to the window moving, MWindow can optionally be an a os window and be moved.

Re: GUI clarification

oups, ok smile I just realized that I gave you a wrong code previously to send events to MWindow :

to send the mouse move event was not "window->onMove(mx, my);" but "window->onMouseMove(MVector2(mx, my));"

sorry, my mistake... I didn't understand why you was talking about a bug in onMove...

I corrected it there : http://forum.maratis3d.com/viewtopic.php?pid=5155#p5155

41

Re: GUI clarification

Oh, lol.... ok...

Yeah now everything works. big_smile

Last edited by 255 (2013-10-04 18:49:48)