Ich habe es mit einer Procedure im Formular versucht, mit einer Procedure in Frame1 oder über
eine Variable in Frame1 usw. knallt immer.
Grundregel:
Pack die uses grundsätzlich unter Interface (nicht unter implementation).* Dann merkst du sofort, wenn du nicht nur in einer Richtung zugreifst.
Das Formular sollte nur Frame1 kennen und Frame1 nur Frame2 (und nicht das Formular), aber Frame2 sollte
niemals Frame1 oder das Formular kennen.
Mit diesen Grundregeln sollte es leichter fallen, das sauber umzusetzen. Hat Frame2 denn schon das passende Event, das den String als Ergebnis übergeben bekommt?
PS: Was ist falsch daran die Frames nach gebrauch mit Free und nil zu entsorgen?
Daran ist erst einmal nichts falsch, aber das sollte nicht das Element selbst in einer Methode des Elements machen. Das wäre als ob du nicht zuerst aus dem Abbruchhaus (Frame2) rausgehst und dem Bagger (Frame1) Bescheid sagst, dass er anfangen kann, sondern im Haus den Boden unter deinen Füßen selbst zertrümmerst. Denn wenn die Methode beendet ist, wird ja das Objekt, das diese aufgerufen hat, weiterarbeiten wollen. Da wäre es doof, wenn das schon freigegeben ist...
Und die Freigabe kannst du dann auch nicht direkt in dem Event von Frame2 machen, sondern z.B. mit TThread.ForceQueue aus diesem Kontext gelöst.
*
Ja, ich weiß, dass es auch Sinn machen kann, das anders zu machen. Aber zur Vermeidung von Kreuzreferenzen ist das nun einmal der effektivste Weg.