5 Replies Latest reply on Oct 30, 2020 10:32 AM by LePo_1062026

    Component authoring or creation nested params

    ANNA_4329736

      I'm creating a component that uses another custom component inside, it works well, but I wanna show and config the component that is inside (nested) of my new component from the new component... So, is it possible to call the configure window of an internal (nested) component from or built-in the configuration window of the parent component?

       

      Thanks!!
      Andres

        • 1. Re: Component authoring or creation nested params
          LePo_1062026

          Anna,

           

          The answer is YES!

           

          If you download my Term component (Terminal Support Component Library ) you will find I embed the UART and USBUART together.

           

          The Term component inherits virtually all of the UART configurable parameters and many of the USBUART parameters.

           

          Sadly, at this time, it is only available as "Expression View".  This means all parameters are field-based entries.   It does not make use of the special customizer code that Cypress created for the embedded component.   I hope to learn how to do that.  (If anyone wants to illuminate me, I would be appreciative.)

           

          The way to do this is a bit elaborate which I am willing to share with you.  However, I first recommend downloading my Term component and then Importing it into a project using the "Component Import" feature.   This way you can see the machinations of using Formal and Local variables to transfer the user configuration to the embedded components.

           

          I'm sure that you will have questions afterwards.   It would be easier to start from there.

           

          If you haven't started reading the "Component Author Guide" I recommend it.   It is good but not all encompassing.  I should be able to help with many of the questions you might have.  If I can't, hopefully one of the other custom component authors will be able to step in.

           

          Len

          • 2. Re: Component authoring or creation nested params
            ANNA_4329736

            Len.

             

            Thank you!

             

            I'll check your component later and come back with more questions!!...

             

            Yes, I read the "Component Author Guide" but it's just the beginning... I feel we need an advanced version with more details of that document!

             

            Greetings,

             

             

            Andres

            • 3. Re: Component authoring or creation nested params
              LePo_1062026

              Andres,

               

              I agree.  There should be an documentation regarding component authoring.   However given that Cypress has been to move away from PSoC Creator and UDB blocks in their PSoC6 products, such a document would have to be generated from forum supporters such as ourselves.

               

              Len

              • 4. Re: Component authoring or creation nested params
                ANNA_4329736

                Len, I was looking at your job on the CONSULTRONLib... That's a good job and excellent material to work on component authoring!!

                However, about my request, the approach you're using is the same I'm implementing and I want to avoid it because it needs to replicate the parameters of the nested component on the parent component again... so in case of the nested component gets an update the parent component will need to be updated/changing the params... My question is focused on finding a way to open directly the configurator windows of the nested devices by request on the parent component or how to direct transparent-pass the params (not copying and paste)...

                 

                Thank you so much!

                 

                Andres

                • 5. Re: Component authoring or creation nested params
                  LePo_1062026

                  Andres,

                   

                  Thank you for the compliment.

                   

                  I agree with you.  The parameters on Term are "copied" from the embedded components (UART and USBUART).   The parameters in Term are "pass-throughs" to these components.   I also prefer to use the Customizers for the embedded components.   A properly designed customizer is more intuitive and easier to use.

                   

                  At this time, I chose the "Expression View" route instead of the Customizer route for two reasons:

                  1. I could have imported the Customizer files and modified them to fit my needs.  However two problems might occur.
                    1. If the original author updates/upgrades the component, I would have to re-import and incorporate my modifications AGAIN.   As you pointed out, this is not optimal in the long term.
                    2. I was trying to avoid reuse of intellectual property of someone else without their permission.  Copying and modifying the Customizer files might be considered under this category.
                  2. I could try to construct my own customizer that launches a 'tab' for my component's unique parameters.   The customizer code would also include the tabs of the embedded components using their customizers.   This eliminates importing proprietary customizer code (more disk efficient) and theoretically minimizes IP violations.  It also potentially allows a more effortless migration of the embedded component updates/upgrades with little to no effort on my part to my component.(?)

                  I'm exploring this last option.  However, there a lot of information and experimentation that needs to occur to make this happen.

                  {If someone who has solved this wants to contribute here ... I thank you in advance.]

                   

                  In the meanwhile, the "Expression view" method as a stopgap measure to use and share your custom component.

                   

                  Len