StretchableObjectResizer bug?

General JUCE discussion
1

I think i’ve found a bug when the currentSize is lower than minSize, and minSize = maxSize. If this happens, the final result can generate numbers that are under the minSize value.

This code fails:

[code] StretchableObjectResizer sor;

Array comps;
comps.add(50); // Max 200
comps.add(1); // Max 6
comps.add(50); // Max 200
comps.add(1); // Max 6
comps.add(50); // Max 200

for (uint8 i=0; i<comps.size(); ++i)
{
const int32 fixMax = ((i == 1) || (i == 3))? 6 : 200;
const int32 fixMin = 6;
const int32 size = comps.getUnchecked(i);
sor.addItem(size, fixMin, fixMax, 0);
}

sor.resizeToFit(200);

for (uint8 i=0; i<comps.size(); ++i)
{
const int32 height = roundDoubleToInt(sor.getItemSize(i));
DBG(String(height))
}
[/code]

It generates:

66 2 66 2 66

Is it a bug? I think it’s

2

Thanks! Should be fixed now, give it a try.

3

Jules, there is another problem with this class. I’m using lastest version (2.0.27)

Its doing weird things. Using this simple code:

[code] StretchableObjectResizer sor2;
sor2.addItem(300, 50, 10000);
sor2.addItem(100, 0, 200);
sor2.addItem(300, 0, 10000);
sor2.resizeToFit(900);

for (uint8 i=0; i<sor2.getNumItems(); ++i)
{
DBG(String(sor2.getItemSize(i)));
}
[/code]

The results should be something like: 366.66, 166.66 and 366.66, however they are: 399.48, 101.02, and 399.48. Maybe this happens because the adjustment depends on the maximum value, if that’s true, could it be avoided?

If you change the second item and do the first value greater than the maximum:

[code] StretchableObjectResizer sor2;
sor2.addItem(300, 50, 10000);

//*** 300 instead 100 **** //
sor2.addItem(300, 0, 200);

sor2.addItem(300, 0, 10000);
sor2.resizeToFit(900);

for (uint8 i=0; i<sor2.getNumItems(); ++i)
{
DBG(String(sor2.getItemSize(i)));
}
[/code]

The results are: 300, 200, 300. They didnt reach 900 even.

I think is a bug.