This is my first time posting, so I will introduce myself a little bit. My name Niels Lewerissa and I'm currently developing robotics solutions within a large insurance company in the Netherlands for about 7 months.
With the "large company" in mind, we are currently struggling to conceive a good solution for reuse of earlier created adapters. The thing is that when we need screens from an earlier created text adapter, we have to interrogate them again into the new adapter (or do some manual copy pasting in te source files).
So at first we were looking into creating a seperate login text adapter and an other adapter for the business logic. Then we could quickly make a reference to login part and reuse it. But there isn't a "stop and unhook" option and neither a "rehook" to an already running application. So when you stop an adapter is stops the application as well.
I know this functionality is not around at the moment, but we trying to find a proper way to reuse adapters without to much copy pasting, because if some screens change we have to go into all the seperate solutions and change all the solutions that are using the adapter. We are currently creating one big adapter that holds all the screens and in that way it can be reused, but it is growing quickly at the moment and maybe to the point that it becomes to big to manage.
I am not sure I fully understand your entire line of questions, however I will try to summarize.
1. Detach/Unhook - You are correct in that you cannot attach to a running process generally, however that is precisely how the text adapter works. You first use a windows adapter to start up the emulator and once the session is started, you start the text adapter effectively connecting to the named short session. In this manner, you could have as many adapters as you wanted connecting to the same session (although not at the same time and this would be a bad idea anyway) as long as you started/stopped the text adapter in between. The Start method for a text adapter basically connects to the short session named in the adapter properties and the stop detaches from it.
2. Organizing your solutions - We recommend that you organize your solution into separate projects. You'd have a "controller" project that references the individual adapter projects and orchestrates the functionality between them in addition to "child" projects specific to each adapter (or really the application itself as a text application should have two adapters). In your example, you'd have a project that performs some automations against your text adapter and you can test that functionality and ensure it works. When you need to make changes to how the login works, or to add new automations to it, you can do so in one place and other projects that use this adapter could simply be re-built to use the new functionality (and regression-tested of course).