i don't really understand the IEventReciever stuff. but all i want to do is that when escape is pressed it will open the gui and it wont close it until escape is pressed again.

In order to do this you need to track the previous state of the button.

i don't really understand the IEventReciever stuff. but all i want to do is that when escape is pressed it will open the gui and it wont close it until escape is pressed again.

Okay. there are two usual ways for input handling, you are doing one of them. I'm not sure which, because I'm not familiar with the library you are using.

One way: Event handling. Very simply put: whenever an input event occurs, like pressing a key, an "event is fired". There is a method/function that gets called when this event occurs, that handles the event. Since an event is an event, it happens only when you push the button, and the associated function is only called in case of that event (details are not so simple, but you get the idea). This method is ideal for the thing you want to do, since you want a thing to happen (changing state) when the specific event occurs.

the other: Polling: directly querying the sate of the button (pushed or not). Usually this querying is done in the game loop, so you are continuously checking the button state, which obviously not so good for events, like a keypress. Because you only know the state of the button, but don't know when the state change happened. This can be solved with a separate variable, that stores the key state. More on this later. (This type of input handling is good for continuous things, like running, steering in a game).

I hope it makes sense, it's important to grasp the difference between the two methods. One cares about state changes, one cares about states.

Your system, based on the function names is polling the input. To solve the said issue with this, you store the state of the key, so you can check if it has changed since the last time you queried its state.

Pseudocode:

[font=courier new,courier,monospace]key_state

in your main loop
{ new_key_state = IsKeyDown([/font][font=courier new,courier,monospace]KEY_ESCAPE[/font][font=courier new,courier,monospace]);
[color=#0000FF]if( new_key_state != key_state && new_key_state == pushed)
{
[color=#008000]// event!! the key state is changed and the key is is pushed, we can act

showGameMenu = !showGameMenu;[color=#008000] //we are toggling
}
key_state = new_key_state; [color=#008000]// we store the key state
}[/font]

See? you need an extra variable.

But as stated above, check the documentation of the library you are using, there may be a build in function for that already, that internally has this extra variable.
something like
[font=courier new,courier,monospace][color=#0000ff]bool IsButtonChanged([color=#0000ff]int key)[/font] or whatever.

It would be awesome if we knew what those functions are actually doing without the need to look them up. Maybe you don't know it either, and just shooting in the dark which may be a bit of a problem.

Or some more info about the whole stuff you are doing. What you posted here might work, but it looks messy to me.

We don't even know what show/hideIngameMenu does. Does it simply renders the menu, or does it also has its internal states to indicate if the menu has to be rendered (somewhere else in the source code)? Does it do initialization/deinitialization stuff?

actually, i figured it out myself at school, its quite a cool way too and its not as error prone as polling

It's still polling - this is actually (a minor variation on) the solution proposed several times earlier in the thread.

actually, i figured it out myself at school, its quite a cool way too and its not as error prone as polling



if(showGameMenu)
{
showInGameMenu();
if(receiver.IsKeyDown(irr::KEY_ESCAPE))
showGameMenu = false;
}
else
{
hideInGameMenu();
if(receiver.IsKeyDown(irr::KEY_ESCAPE))
showGameMenu = true;
}


just leaving it here incase others have the same problem

How does that fix the problem? If you hold down ESC, it will just switch between menu states every time through. You need to do what szecs proposed.