There is several ways to do this but this example simply show you how you can "trick" your way out of it.
What we do here is simply copying the text in question to a global variable with SetVar() and then we switch to the other form and click on a button that perform the MemoCopy().
In DE9 we have changed how we work with strings so all strings can be up to 4gb long which makes all this much simpler. In effect all Memo functions are rendered void in DE9 as you can simply use String functions like Concat() etc.
DFW has tthree distinctly different models which one need to understand to successfully do things like this.
1. PRISM (Data level).
2. GUI (Document manipulation).
3. MULTIVIEW (Cursor, column level).
Here you manipulate the data but this is not necessarily reflect in a document that use these data. You can think of it as changing the data from a DQL when the form is open. The data is changed in the table but you can't see it.
If you try to save a form after running the DQL you will get a message saying the data is changed since read.
Here you change with functions what is seen in the form but the changes is not saved or reflected in the database. So you will need to save the form before the changes are reflected in the Database.
This is the cursor read from the database based on the form layout (with subforms, virtual fields etc). This contain all the rows from current search/query. You can manipulate this level (MemoCopy does) but the result will not necessarily be reflected in the form before you save and re-read. This is why we do a RefreshForm() after MemoCopy manipulation.
I guess all of you have tried to string together functions like RecordSave()+DocumentOpen("MyForm")+ etc.
And sometimes it work the way you want and some times not... This is due to how the WIndows model work. In DFW (or Windows really) you don't send messages to a specific form/document but to all of them but only the Active Window will act on them.
So when you string functions together like above you will at some stage not send the message to the Window you execute the functions in but the window you open with DocumentOpen().
This is a problem but also an opportunity which we have exploited here.
As you can see from above, we first set the tempvar so we can carry the data over to the new form, then wee change the ActiveDocument to Form2, call a little wait to make sure we send the Click to the correct window and then we click the button in the new window.
You can also use a Timer() in OML to control message handling between window but as the TImer() event conflict with Import functionality in DE85 it is not recommended to use it unless you switch it off when you use Imports.
A Timer() event is Global so you can in effect have one Timer() event that control you application. The Timer() event is a property of the Form object and you can have one on each document but in reality you should only have one as you can then control execution order.
In DE9 you have a complete event engine in ServiceWindows that can help you control the entire application to behave exactly like you want.
The event engine will be triggered on all major events like selection change, document open, save etc. and you can simply put handling on the events you want. The toolbars/menus etc. in DE9 is all ServiceWIndows and all the handling is controlled through this engine both in DT and RT. So in principle you can make your own DataEase 9.