Site navigation

How can you know each component characteristic?

General JUCE discussion
#1

In order to scan all of components and to save the result on screen to file inside a window, you may use following code.

    for ( i = 0 ; i < getNumChildComponents(); i ++ )
        child = getChildComponent (i);

How can you know what the each component is ?
for example:
for ( i = 0 ; i < getNumChildComponents(); i ++ )
{
child = getChildComponent (i);
if(child->type == String(T(“Combobox”))
{
getName();
save the data in file;
read current selected value();
save the data in file;
}
else if child->type == String(T(“Slider”))
{
getName();
save the data in file;
read current value();
save the data in file;
}
}

the purpose of this approaching is to save current status in file and load the status in future without knowing each component pointer and reload with referent name.

Additionally, you can make only one easy code to handle for many window. you don’t need to know each component to write code inside each window.

is it possible ?

#2

if ( Slider* slider = dynamic_cast<Slider*>( child ) )
{
slider->someSliderSpecificMethod();
//etc
}
else if ( TextButton* button = dynamic_cast<TextButton*>( child ) )
{
String t = button ->getButtonText();
//etc
}

and so on…

#3

hey, that’s a neat trick - i never knew that was what dynamic_cast could be used for!

#4

Yep. But don’t abuse it! lol

The OOP puritans out there frown upon the downcast as an indicator of bad design. but like “mutable” it has its uses.

#5

yeah, personally i’d prefer to have a more rigid system in place.

in this example, you have to put the code in to handle each type of component anyway; this implies that - whilst it ‘works with any component type’, it clearly doesn’t work with ANY component as you have to put the code in yourself; thus what i’d do is code the components to have this behaviour in them: a ‘SaveableComponent’ base class perhaps, with a virtual ‘doMySaveStuff()’ function, then i’d have a SaveableSlider which simply inherits Slider and SaveableComponent defining that function/s. The code has to go in anyway, it’s probably better for it to be a more robust model. That makes your stepping thru routine more sensible too [an array of SaveableComponent pointers just calling the virtual function].

it’s all in the design!

#6

I work with one library where that’s the way to access custom code you add to a class - the library tracks the super-class (and returns it to you from some methods), then when you add methods to your class you need to dynamic cast it. It works very well in practice, and it’s safe. If you have RTTI activated (as Juce requires) you may as well use it.

But is also seen in some poor C++, that’s for sure.

Bruce

#7