Changing component instance

Author: richard.gill@agfa.com (richard.gill)

Hi

I discovered recently one DSP can ask its container to change the value in the container (so the DSP which makes the request). This not work, until you clearly define scopes to limit the current DSP to input :

PARENT
+- DSPCONT = CHILD1

CHILD1: BUTTON.detail
scope
    input
endscope
activate "PARENT".changeChild()

PARENT.changeChild
DSPCONT = CHILD2
 

But this does not work when the child is a fixed name instance.

PARENT.exec
scope
    output
endscope
newinstance "CHILD1", "CHILD"
DSPCONT = "CHILD"

CHILD1: BUTTON.detail
scope
    input
endscope
activate "PARENT".changeChild()

PARENT.changeChild
DSPCONT = ""
deleteinstance "CHILD"
newinstance "CHILD2", "CHILD"
DSPCONT = "CHILD"
 

In the changeChild operation, the deleteinstance stop ANY processing (even in the debugger, debugging stop their and we have a runtime error). If we remove the deleteinstance, the newinstance does not work (-154 : instance already exists ).

No way to make this work? (I tried with a button in the parent changing the component affected to the DSPContainer, same result)

 

2 Comments

  1. Hi Richard

     

    I have not quite understood if you have something that does not work or if you are explaining a use for scope.

    If it helps, I have a pop up script.

    So, if you are in a dsp container1 and you click on a button, you can choose from dsp container2 an item1 to fill in dsp container1.

    Also, if you were to press a diffeent button, it would display also dsp container2 but with a differnt dsp item2 to fill.

     

    Thanks

    Osie

     

     

     


    Author: osie_osie (osieman@gmail.com)
  2. Hi Osie

    The first part of my message explains a special use of scope, one in which a DSP asks its container to remove it from the DspContainer.

    The next part explains a problem, a specific case of the above, where this does not work. The case is when the contained DSP is to be replaced by another DSP, but with the same instance name.

    Cheers,
    Richard


    Author: richard.gill (richard.gill@agfa.com)