Das sind denke ich schon 2 unterschiedliche Probleme.
Problem 1: Menü. Wie du schon weißt ist das Menü kein Unterobjekt der Form. Das Wurzel"objekt" eines Menüs wird per DEFINE MENU ewrzeugt und hat zur Nutzung in DEFINE BAR und anderem einen Namen. Der Muss eindeutig sein.
Problem 2: Um von Formular1 ein anderes Formular anzusprechen, brauchst Du dessen Formularreferenz. DO FORM ist dafür in der Grundform ungeeignet, weil es Dir keinerlei Referenz zurückliefert, es startet einfach nur das Formular und so gestartet hast Du
keine Referenz, um das Formular von woanders here anzusprechen, außer den Namen. Anders als beim Menü, was nicht OOP ist, ist der Name hier aber nur eine zweitklassige Referenz, denn jedes Form hat als Namen Form1.
Mach mal zur Anschauung im Command Window Do Form... und dann ACTIVATE WINDOW FORM1 mehrmals, das wird dann immer zwischen beiden Formularen Wechseln. In VFP9 sind wir Objektorientiert und machen Formularklassen, die man instanziiert per oForm = CreateObject("meinFormualr")
und dann hat man eine Formularreferenz an der Hand: oForm.
Rettung naht, denn DO FORM hat noch eine Klausel, mit der man auch so eine Referenz erhalten kann: NAME.
Kurz gesagt so:
DO FORM xyzt NAME oForm
oForm.Caption = "Huhu, mein Windows Titel hat sich geändert..."
Zehn Schritte zurück: Empfehlenswert ist eine Klasse "Formularmanager", die Formulare Startet, schon gestartete Formulare aktiviert, Formularreferenzen bereitstellen kann, damit zwei Formulare sich gegenseitig beeinflussen können etc. Der Grund dafür ist,
daß Formularreferenzen irgendwo so gespeichert werden müssen, daß Sie nicht gleich wieder aus dem Speicher Releast werden, wie Private oder Locale Variablen.
Da ich Dir so einen Formularmanager jetzt kaum Vorexerzieren kann: Für den Anfang könntest Du zur Lösung des Problems Äbäh) Public Variablen nehmen und jede gestartete Form in eine solche Variable speichern. Auch die müssen natürlich dann jeweils unterschiedlich
heißen. Aber damit hättest Du dann auch in Formular1 eine Referenz auf Formular2 und ungekehrt.
Das Konzept Ausgabefenster ist dabei unüblich, zumindest die Ansteuerung weiterer Formulare. Du hast ja Datenbindung, Du kannst als z.B. das Anzeigeformular mit Grid an eine Tabelle binden und im Formular1 in diese Tabelle schreiben, woraufhin dann im Anzeigeformular
diese neue Zeile angezeigt wird, das ist eine sauberere Lösung als Formulare sich gegenseitig per Herumfummeln an Control Values zu beeinflussen.
Tschüß, Olaf.
PS: Noch ein Tipp dazu:
Ein Collection-Objekt ist ideal zum Speichern aller Formularreferenzen aktuell laufender Formulare. Es gibt zwar schon ein Array unter _Screen.Forms(), aber das hält die Formulare nicht am Leben, außerdem kann man bei einer Collection beim Add einen Schlüssel
angeben, unter dem man das Formular wiederfinden möchte, was einfach der Formularname sein kann. So kann man dann auch leicht in der Collection schauen, ob ein bestimmtes Formular schon gestartet ist und dann evtl. nur aktiviert werden muss, in _Screen.Forms
müsste man dazu alle Formulare auf ihren Namen oder ihre Klasse prüfen. Formularreferenzen tilgen sich auch automatisch aus einer Collection, wenn ein Formular per X oder RElease() geschlossen wird.
