[Clam-devel] resizing InControl arrays (canvas display bug?)

[Hernán Ordiales]

On 7/13/07, Hernán Ordiales <h at ordia.com.ar> wrote:
> > > 2) Above code is working but there is a bug when you shrink controls
> > > amount... (for example from 5 to 2) incontrol std::vector shrink seems
> > > work ok, but seems related to canvas display, don't?
> > >
> > > how can I avoid this?
> >
> > It is a bug. See when a ProcessingBox gets initialized (with its
> > number of ports). It seems that we need to call this init method
> > after configuring a processing.
>
> ok, thanks!

talking about this at irc with David, he made me notice that for
example AudioMixer (which also has configurable in-controls) is
shrinking (in-controls amount) without problems, then is not a problem
with canvas...

but here arise another isssue, audiomixer seems to work with a local
implementation of std::vector of InControls.. not InControlArray
one... then there are duplicate code (at least at first sight) and
InControlArray seems to provide a cleaner and more understandable
interface...
should I also update audiomixer to InControlArray ?

indeed, before that i've checked it and ProcessingBox::configure seems
ok, is calling setProcessing who calls refreshConnectors().

i've also checked ControlArray implementation of resize, shrink, etc
and all seems ok but seems that indeed when you shrink is trying to
get in-controls names of destroyed ones or something like that

i'm only calling a resize of InControlArray from ConcreteConfigure...
works for expand but not fro shrink...

clues?
-- 
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9