Office: (Office 2003) Prüfen auf geöffnetes Unterformular

Hallo zusammen,

mittels

Code:

kann man ja auf ein geöffnetes Formular prüfen.

Nur wie prüfe ich, ob ein Formular als Unterformular geöffnet ist ?
(acForm durch acSubForm ersetzen half nichts)

Grüße

:)

 

hm ... benötigt habe ich so etwas bisher noch nie, aber aus Neugierde versuchte ich so etwas:
Code:

Anm.: Set f = Form_UF_A gibt entweder eine bestehende Instanz des geöffneten Formulars (egal ob als HF oder UF) zurück oder erzeugt eine neue Instanz, die dann mit AllForms("UF_A").IsLoaded abgefragt werden kann - das bedeutet dann, dass das Form nicht als UF geöffnet ist.

 

Hey,

deine Anmerkung bereitet mir gerade Probleme.

Wenn ich deine Lösung in einen Funktion stecke, welcher ich dann den Namen des Formulares übergebe

Code:

bekomme ich die Meldung, die Variable (rot) sei nicht definiert

 

Form_xxxx in set f = Form_XXXX ist auch kein String sondern der Bezug zur Klasse.
Analog set f = new Form_xxxx
Das kannst du in nicht in eine Prozedur stecken, die den Teil nach "Form_" als String übergeben bekommt, und dann wie einen String zusammensetzen.

Aber gehen wird die Sachen einmal von der anderen Seite an: Wozu benötigst du das eigentlich?

 

Eine spontane Idee: ein UFO müßte doch immer ein "parent" haben.

 

Der Hintergrund dahinter ist, ich wollte meine Formular etwas wartungsfreundlicher gestalten.

Ich habe eine Hfo - Ufo (Endlos) Konstellation

Wenn ich ein weiteres Formular, bspw. als Dateneintrageformular öffne, aus dem Ufo heraus öffne, benötige ich in diesem Eintrageformular ja Kenntnis der Fremdschlüssel, die im aufrufenden Formular existieren.
Diese kann man ja einerseits in unsichtbare Textfelder in das Eingabeformular schreiben lassen, aber dann schwirren in der Entwurfsansicht Felder herum, die man vielleicht mal irgendwann übersieht / vergisst ...

Und da dachte ich, das Eintrageformular kann ja direkt Bezug auf die Fremdschlüsssel nehmen, da jedoch je nach Fall 3 Ufos relevant sein können, dachte ich es wäre das einfachste wenn man dies so löst .... man also schaut welches Ufo denn geöffnet ist und dann die richtigen Fremdschlüssel holt

Nuja, ich dachte es sei einfacher, aber ds ist dann wohl nicht so *Smilie

Dankeschön dennoch

Grüße
flew

 

Wenn 3 Ufos gleichzeitig offen sind, wie soll dann das eine Formular wissen, welcher Wert verwendet werden soll, wenn du ihm die Form-Ref. zum passenden Ufo nicht mitteilst?

Bezüglich Datenübergabe von einem Formular in ein anders nutze ich gerne Property-Prozeduren. Damit bleibt es dem Formular überlassen, wie es die übergebenen Werte speichert.
Zugriff auf Steuerelement von einem Formular aus einem anderen Formular finde ich bezüglich Wartbarkeit nicht besonders gut. Damit schränkt man sich imo viel zu sehr ein.
In meinen Anwendungen sind die meisten Formulare vollkommen unabhängig von den anderen. Verbunden werden sie mittels Property-Prozeduren, öffentlichen Methoden und Ereignissen.
Das ist zwar beim erstmaligen Erstellen etwas mehr Aufwand, macht sich aber mit der Zeit bezahlt, da der Aufbau sehr flexibel ist und ich jederzeit ein Formular umgestalten kann, ohne andere Formulare ändern zu müssen. (Nur die Schnittstelle muss erhalten bleiben.)

 

Moin,

bzgl der 3 Ufos hatte ich es so vor, dass ich aus diesesn drei Ufos ein und dasselbe Formular öffnen kann, natürlich nicht gleichzeitig.
Dieses geöffnete Formular sollte dann schauen welches Ufo geöffnet ist, also von welchem Ufo heraus es aufgerufen wurde, sodass es dann erkennen kann, welche Werte es nehmen soll.
(Wenn UfoA offen, dann nimm cboA, ...UfoB dann cboB .......)

Property Prozeduren sagen mir erstmal nichts, ich werde mal suchen was das ist und ob ich damit umgehen kann.


Grüße
flew

 

\@flew: vielleicht solltest Du mal auf Josef´s HP stöbern. Mit dem FormSync-Beispiel solltest Du fündig werden.*Smilie
@josef: Bei dieser Gelegenheit mal ein grosses Lob für Deine HP *Smilie

 

Genau diese Konstrukte meide ich. (Direktzugriff auf Steuerelemente)

Wenn es nur um eine Wertübergabe geht, könntest du den Wert aus der Combobox auch per OpenArgs-Parameter übergeben.

Oder eben mittels Property-Prozedur:
Code im aufgerufenen Formular:
Code:

Oder falls dir eine normale Methode lieber ist:
Code:

Code in den UF:
Code:

Falls du den Wert in der jeweiligen Combobox füllen willst, kann ich dir ein benutzerdefiniertes Ereignis empfehlen. Dann wäre es sogar egal, wenn mehrere UF gleichzeitig auf das Formular reagieren.
Beispiel: EventForm (Wertübergabe per Ereignis)

 

Ein anderer Gedanke: Da ich ein einfach denkender Mensch bin, vermeide ich aufwendige Formular- und Instanzenkonstruktionen und hole mir lieber die benötigten Informationen direkt aus der Datenbasis, also aus Tabellen und Abfragen.

 

Wenn ich hier nochmals nachhaken darf ...

Wenn ich diese public property Let ... Konstellation bei einem Formular anwende, welches ein Popup (Formular zum Werte heraussuchen) öffnet und bei Schließen dieses Popup Formulars auf die property Let des öffnenden Formulars vom Popup Formular aus zugreife, bekomme ich einen Anwendungs- oder objektdefinierten Fehler (Laufzeit Fehler 2465).

Scheinbar geht diese Konstellation nur in HF - UF Beziehungen ?

Wie übergibt man denn sauber Werte von einem Popup Formular an das öffnende Formular ?
(Das Popup Formular kann von verschiedenen Formularen aufgerufen werden)

 

Z. B. mittels Ereignis. *Smilie
Beispiel: http://access.joposol.com/downloads/...eventform.html

/Edit:
Hoppla, das stand ja bereits im Beitrag #10.

 

uff das sieht aber schwierig aus,
also vor allem viele neue Befehle etc. ...

Ich werde versuchen durchzusteigen, danke dafür !

 

hoffentlich sieht es nur so aus. *wink.gif*

Vermutlich werden sich diese vielen neuen Befehle auf drei beschränken:
1. Deklaration eines Ereignisses
Code:

2. Auslösen eines Ereignisses
Code:

3. Deklaration mit Withevents
Code:

Der restliche Code zum Reagieren auf die Ereginisse ist wie bei den in Access eingebauten Ereignissen.
Bezüglich benutzerdefinierten Ereignissen beschrieb ich einmal ein Beispiel etwas ausführlicher (Ereignisse - Die Nachrichtenverbreiter von Klassen). Vielleicht hilft dir das etwas.