GUI options into variables
-
- Posts: 109
- Joined: Tue Jan 09, 2007 1:18 pm
GUI options into variables
What's the best way to make GUI elements like checkboxes and input boxes easily into code variables? For example I want to have a checkbox and use that as a boolean in the code with as least code as possible. Templates, macros, snippets anyone?
Crimson Glory full Irrlicht game source code!
What I Do - my blog & dev log
Currently developing Link-Dead
What I Do - my blog & dev log
Currently developing Link-Dead
You save the IGUICheckBox pointer, which is returned when you create such an element, in a variable and call isChecked () for that (which already returns a bool).
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
-
- Posts: 109
- Joined: Tue Jan 09, 2007 1:18 pm
Lets say I dont want to keep pointers.
I want something like this.
bool var = true;
addcheckbox( var );
*change checkbox in GUI to unchecked*
var = false
I want something like this.
bool var = true;
addcheckbox( var );
*change checkbox in GUI to unchecked*
var = false
Crimson Glory full Irrlicht game source code!
What I Do - my blog & dev log
Currently developing Link-Dead
What I Do - my blog & dev log
Currently developing Link-Dead
Ok, I just assume you really know what you do, as this sounds like you are running in danger of violating the DRY principle (http://c2.com/cgi/wiki?DontRepeatYourself) and that's nearly always a bad idea.
You won't get around using a IGUICheckBox pointer sometimes, as that is certainly the only way to do any changes to a checkbox object. So at least for setting the state you will need it. I suppose you also want to catch the change-event and you do that in your eventreceiver.
You don't absolutely need to keep the pointer for that. You can also set an ID to the object and compare for that. Then you can save an integer instead, though I don't see any advantages that way (you even lose some type information). Or if you're not afraid of hacking Irrlicht you can add some strings for names to IGUIElement and use those instead of ID's (I do that usually, as I don't create elements manually but with XML's and working with integers gets rather confusing in that case).
And certainly you can also start hacking on the event-system and try to make that more comfortable. I usually replace it with event functors - that way receiving events is a little more comfy than by using endless switch/case checks.
You won't get around using a IGUICheckBox pointer sometimes, as that is certainly the only way to do any changes to a checkbox object. So at least for setting the state you will need it. I suppose you also want to catch the change-event and you do that in your eventreceiver.
You don't absolutely need to keep the pointer for that. You can also set an ID to the object and compare for that. Then you can save an integer instead, though I don't see any advantages that way (you even lose some type information). Or if you're not afraid of hacking Irrlicht you can add some strings for names to IGUIElement and use those instead of ID's (I do that usually, as I don't create elements manually but with XML's and working with integers gets rather confusing in that case).
And certainly you can also start hacking on the event-system and try to make that more comfortable. I usually replace it with event functors - that way receiving events is a little more comfy than by using endless switch/case checks.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
If you absolutely insist on not dealing with the checkbox directly, you can create a class that hides it. Something like this...
Travis
Code: Select all
class CBooleanOption
{
// no assignment or copy
CBooleanOption (const CBooleanOption&);
CBooleanOption operator= (const CBooleanOption&);
public:
CBooleanOption (bool value, IGUICheckBox* checkBox)
: CheckBox (checkBox)
{
CheckBox->grab();
CheckBox->setChecked(value);
}
~CBooleanOption ()
{
CheckBox->drop();
}
// allow assignment from bool
void operator=(bool value)
{
CheckBox->setChecked (value);
}
// allow conversion to bool
operator bool () const
{
return CheckBox->isChecked ();
}
IGUICheckBox* getCheckBox ()
{
return CheckBox;
}
private:
IGUICheckBox* CheckBox;
};
-
- Posts: 109
- Joined: Tue Jan 09, 2007 1:18 pm
That class doesn't look bad, thanks.
The problem is, I lose the value when the GUI element is destroyed. This is a game GUI so it exists only when the player presses ESC and goes to menu. But I need those values in the game. Am I doing something wrong?
The problem is, I lose the value when the GUI element is destroyed. This is a game GUI so it exists only when the player presses ESC and goes to menu. But I need those values in the game. Am I doing something wrong?
Crimson Glory full Irrlicht game source code!
What I Do - my blog & dev log
Currently developing Link-Dead
What I Do - my blog & dev log
Currently developing Link-Dead
To me it seems that you're going about it the wrong way and expecting things to work a bit simpler and easier than they actually do so you're expecting too much from it.
I think in all my irrlicht games i had all the menu guis around all the time and just made them visible/invisible as required, though if you've got a big game that probably wouldn't be so feasible perhaps.
What you can do is just store the value of the checkbox somewhere when the user changes it and then when you're in game you've got that value stored safely for use.
I think in all my irrlicht games i had all the menu guis around all the time and just made them visible/invisible as required, though if you've got a big game that probably wouldn't be so feasible perhaps.
What you can do is just store the value of the checkbox somewhere when the user changes it and then when you're in game you've got that value stored safely for use.
-
- Posts: 109
- Joined: Tue Jan 09, 2007 1:18 pm
The thing is I also have console variables. So I want to have one system for all of it. That's why I'm looking for ideas.
If I change for example a variable int num_players, I want it to affect the proper GUI element without me having to do specific code for it.
If I change for example a variable int num_players, I want it to affect the proper GUI element without me having to do specific code for it.
Crimson Glory full Irrlicht game source code!
What I Do - my blog & dev log
Currently developing Link-Dead
What I Do - my blog & dev log
Currently developing Link-Dead
Depending on if it can wait till the end of a frame, you can have an update function that sets all your gui controls to equal your gui variables (by doing it the normal, hard way), and call this function each frame. When you change the variable, it'll get automatically handled at the end of the loop by this function.
btw, Moloko, or should I say Michal, I love Soldat! I've been playing it since 1.2.1 and played it for years. I stopped 2 years ago at around 1.3.1 because something in the netcode screwed up my playing style. Before, I would only use the chainsaw and grenades (my name was Saw 'n Nades, and I was pretty awesome ), but in 1.3.1 I could no longer killed with 1 hit from my saw or nade. Sometimes it took 4 nades to kill someone. I bet it's fixed now; maybe I'll take another look at it now.
Anyways, it's cool to see you using Irrlicht. Soldat has played a part in inspiring me to make my own game.
btw, Moloko, or should I say Michal, I love Soldat! I've been playing it since 1.2.1 and played it for years. I stopped 2 years ago at around 1.3.1 because something in the netcode screwed up my playing style. Before, I would only use the chainsaw and grenades (my name was Saw 'n Nades, and I was pretty awesome ), but in 1.3.1 I could no longer killed with 1 hit from my saw or nade. Sometimes it took 4 nades to kill someone. I bet it's fixed now; maybe I'll take another look at it now.
Anyways, it's cool to see you using Irrlicht. Soldat has played a part in inspiring me to make my own game.
-
- Posts: 109
- Joined: Tue Jan 09, 2007 1:18 pm
Yeah I fixed those collision bugs in version 1.4 (it's 1.4.2 now).
Crimson Glory full Irrlicht game source code!
What I Do - my blog & dev log
Currently developing Link-Dead
What I Do - my blog & dev log
Currently developing Link-Dead
-
- Posts: 8
- Joined: Sun Apr 20, 2008 5:36 am
- Location: Albeta, Canada