4 Replies Latest reply on Oct 12, 2016 10:47 AM by Rick E Johnson

    Can separate tool plugins share a common tool group/box?

    Rick E Johnson Level 1

      I have several plugins that contain tools, and would like all of these tools to reside in one common tool box, or group. Since they're all separate plugins, a user could have any combination of them. I can iterate through a list of toolboxes, but is there a straightforward way to determine if a toolbox contains one of MY plugins besides checking the name of every one? I'll write more plugins in the future with tools that should be added to the same group, so relying on names is only partly effective.

       

      Any suggestions would be much appreciated!

        • 1. Re: Can separate tool plugins share a common tool group/box?
          A. Patterson Level 4

          Well, you could just use the same name (internal unique name) for the toolbox in every plugin. Looking at the SDK, it's odd, but while you can iterate toolboxes, you can't ask for information about a given toolbox, which is strange. You'd have to try it, but it might be that if you ask to create at toolbox with a name that's already in use, it might just return you the handle of that toolbox. Or it might give you an error, which wouldn't be much help

           

          Note that at a certain point (CC2015.3 I think?) the user can create their own toolboxes and move tools around, so it may be that the best you can do is give a default starting toolbox for a tool.

          • 2. Re: Can separate tool plugins share a common tool group/box?
            Rick E Johnson Level 1

            That's pretty much what I'd hoped to do, except my interpretation of the function to give a toolbox a name when creating it was that the name had to be the unique identifier of the plugin, which would explain why there's no function to get the name of a toolbox.

             

            I'd wondered about the practicality of storing the first AIToolHandle (or AiToolboxHandle) used in a small file. At startup, each plugin would look for the file, read it if they find it, create it if they don't, then come back at post-startup and delete it if it's still there. Of course, I need a way to test the handle in case it's leftover from a previous crash during startup.

             

            Does that sound practical? :-/

            • 3. Re: Can separate tool plugins share a common tool group/box?
              A. Patterson Level 4

              Handles aren't persistent between sessions, so I'm not sure that's a great idea. Still, broadcasting the handle isn't a bad one.

               

              You could have all plugins attempt to create the toolbox, and if they succeed, they could send out a notifier with the toolbox handle as a parameter. You can define your own notifiers (e.g. "MyPlugin_toolbox_notifier") and since you have to request to listen for it, only you would ever catch it. A plugin could catch the notifier and stash the handle, and when it's their turn to make the tool, if it's not null, use that instead of attempting to create the toolbox.

               

              This is all assuming that asking for a toolbox named "something" when one with the name "something" already exists doesn't just have it return the handle to that toolbox. It's worth testing first; if you get an error when it already exists, then try the notifier system.

              • 4. Re: Can separate tool plugins share a common tool group/box?
                Rick E Johnson Level 1

                I thought deleting the "handle" file at post-startup would solve the inter-session discrepancy, but checking the age of the file before trusting it might be a sufficient backup check in case of a crash between its creation at startup and deletion at post-startup.

                 

                I'm writing the plugin using CORE, which includes a class that handles inter-plugin communication in much the way you describe. I'd hoped for something simpler that I could write once in a class, then simply include or subclass in one neat package because of the number of separate tool-type plugins I have in the works.

                 

                I'd hoped there might be a way for third-party plugins to use a built-in tool group trick, but at least the shared toolbox is doable, one way or another.

                 

                Thank you for your thoughts and observations!