A common way to accomplish this is to have each modifiable class export a list of 'properties', where the property includes the variable name, a method to update the variable, and the type of edit control that should be used in the GUI. Then the Editor GUI just loops over the properties for the selected item, and displays the corresponding edit controls.

In a (hypothetical) python example, my objects might look like this:

class SpaceShip:
properties = [
Property(name='name', editor=String)
Property(name='speed', editor=Slider(min=1, max=100))
Property(name='colour', editor=ColourPicker)
]


A common way to accomplish this is to have each modifiable class export a list of 'properties', where the property includes the variable name, a method to update the variable, and the type of edit control that should be used in the GUI. Then the Editor GUI just loops over the properties for the selected item, and displays the corresponding edit controls.

In a (hypothetical) python example, my objects might look like this:

class SpaceShip:
properties = [
Property(name='name', editor=String)
Property(name='speed', editor=Slider(min=1, max=100))
Property(name='colour', editor=ColourPicker)
]


I do something similar to this, but I let the editor choose which control is suitable for modifying a value as I don't like to have any tool-related code in my engine code

I do something similar to this, but I let the editor choose which control is suitable for modifying a value as I don't like to have any tool-related code in my engine code

Agreed, but in that case you need some way to expose constraints for a given property (min, max for numbers, length for strings, allowable values for enumerated types, etc.).

[quote name='Radikalizm' timestamp='1348089457' post='4981832']
I do something similar to this, but I let the editor choose which control is suitable for modifying a value as I don't like to have any tool-related code in my engine code

Agreed, but in that case you need some way to expose constraints for a given property (min, max for numbers, length for strings, allowable values for enumerated types, etc.).
[/quote]

I built a system which allows me to store most of these constraints as part of the property objects themselves. I can't say that the system works completely like I would want it to as it gets pretty tough to build a system which can generically store any property with any type of constraint (C++ doesn't really provide any help here either), but it gets the job done.

I've thought of taking the Qt route by building a generic property system with the use of a pre-processor, but I really don't like the idea of cluttering my build process.

Nice, I was experimenting with an approach like this. My implementation feels a little fragile because of storing pointers to functions with different signatures on the engine side and casting them back to the correct type in the editor. But I guess it's a managable problem when there aren't too many property types. Still I'd love to see the "correct" way to implement this in c++

I don't think there really is a "correct way" to do this in C++, IMO. It's all about what your requirements are.

Storing pointers to do this does sound sketchy to be honest, could cause a lot of problems if a pointer suddenly gets invalidated for some reason.

What my system does basically comes down to this: It serializes the contents of the object it's trying to manipulate into something called an "Attribute Set". An attribute set contains a collection of generic attributes with the serialized value, type data, and as mentioned above some basic constraint data.
Objects which can provide this data also provide a way for building or modifying their content from such a generic attribute set.
This creates some interesting possibilities, you could use an attribute set for writing out the state of your object in any format you want for example. This means you could pass an attribute set to your editor, let it modify the values, and send the set back to the object you were editing so it can change its values internally. This means no messing with pointers, no potentially unsafe operations, and the object still remains in control of its own state, as opposed to messing with pointers.