In the training materials and I think in best practices, the suggestion is made that StringUtils, MessageDialog, Pause, and similar commonly used tools be placed in the Global Container. I tend to not do this because I want to create reusable Automations. If these tools are stored locally, I can just import the .os file into another project and I don't have to do a thing. If the tools are in the Global Container, then I will need to replace each instance of the tools in the automation with the new ones in the new project's Global Container -- unless there is some slick way to do that that I don't know about.
So my question is whether this preference to put the tools into the Global Container has any other justification other than that you don't need to keep moving StringUtils, MessageDialog, Pause, etc. into each new automation. Yes, it might use more memory, but who cares in this day and age. Am I missing something?
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
What you are doing is fine and the reason is a good reason. In general we recommend placing these controls in a Global Container to make them easier to find. Having more than one will not affect memory usage. Its a slippery slope though, once you start placing controls in an automation the next step is placing global variables and scripts in there as well. What I do when I want to have portable automations is I create a Global Container for those automations. When I copy the automation I copy the Global Container as well.
Thanks for the kind answer, Jeff! One thing I wonder about is whether it would make sense to have a Global Container template with those tools in them. They should have the same object IDs, so replacing the tools wouldn't be necessary.