To IPC or not to IPC?
The first question I would ask is - are you wanting to add functionality to application A which will allow it to be controlled by application B, or are you creating application B to control application A regardless of whether application A wants it?
In other words, should the servant (A) be 'expecting' to be controlled by the master (B)? If so, it makes things a lot easier since instead of trying to find a specific textbox on a specific form, and then change it, you can use a neat little thing called Interprocess Communication (IPC) to let B ask A and then let A change its own textbox - much more polite, don't you agree? There are various approaches to IPC depending on how much the two applications need to talk to each other, but a good start would be looking at the
System.Runtime.Remoting namespace and child namespaces, and of course do a search for IPC-related code.
If on the other hand A isn't expecting to be controlled by B, you may have to deal with finding window handles and such via good old Win32 API. However, I don't know the entire framework inside out, especially the GUI-related namespaces, so its very possible that there is a neat way of doing it within the confines of the framework.
Good luck