Office: (Office 2019) 1UFO für 2HFO

Hallo Excel freunde,
hoffe Ihr könnt mir bei der Umsetzung helfen.
Meine Basis ist ein Formular mit 2 Button (Neue Messung; Messung Bearbeiten)
Jedes der Formulare hat einen Button mit dem Namen "Kennziffer" und ein dazugehöriges "Textfeld1"
Nun gibt es ein Formular "Kennziffer", in dem ich eine Kennziffer auswählen kann und über einen Save Button speichere.
(Entweder Neue Messung.textfeld1 oder Messung Bearbeiten.textfeld1)
Nun zu meinem Problem, wie zeige ich dem Formular Kennziffer ob es vom Formular "Neue Messung" oder von "Messung Bearbeiten" aufgerufen wurde bzw. wohin der Wert übergeben werden soll.

LG

 

...indem Du einer öffentlichen Variablen bei Klick auf die Buttons einen entsprechenden Wert zuweist, den Du im Formular auswerten lässt...

 

Dazu braucht es keine globale Variablen, sondern du rufst in der Button Click Routine einfach eine Public Procedure/Funktion des UFOs auf und übergibst den eigenen Namen der Userform.

Beispiel:

Code:

' im 1. HFO und im 2. HFO
Private Sub CommandButton1_Click()
  ufm.DoSomething Me.Name
End Sub

Code:

' im UFO ufm
Public Function DoSomething(ByVal Info As String)
    Debug.Print "DoSomething:"; Info
End Function

Knobbi38

 

Anstatt einer Procedure/Function kannst du natürlich auch eine Public Property verwenden, z.B. "Parent", der du das aufrufende Object zuweist:

Code:

' im 1. HFO und im 2. HFO
Private Sub CommandButton1_Click()
  Set ufm.Parent = Me
End Sub

Code:

' im UFO ufm
Private m_frmParent As Object

Public Property Get Parent() As Object
  Set Parent = m_frmParent
End Property

Public Property Set Parent(ByVal ParentForm As Object)
  Set m_frmParent = ParentForm
 
  Debug.Print "New ParentForm", m_frmParent.Name
End Property

Private Sub UserForm_Terminate()
  Set m_frmParent = Nothing
End Sub

Eine andere Alternative wäre, dass das UFO als Event Sink für die beiden HFOs fungiert, ähnlich wie bei einem gemeinsamen Eventhandler - aber das führt hier vielleicht zu weit.

Knobbi38

 

Das sehe ich auch so, dass man soweit es sinnvoll ist, statt Public Variablen besser in eine Property Anweisung packt. Das ist vor allem aus Stabilitätsgründen, da private Variablen bei Fehlern nicht entladen werden, vorzuziehen.

Gruß Uwe

 

Hallo,
erstmal Danke für eure hilfe.
@knobbi38
Könntest du mir zeigen wie ich deinen Vorschlag umsetzen kann/muss

Code:

Private Sub btn_KennzifferSuchen_Click()
Set ufm.Parent = me
frm_Kennziffer.Show 'wert
End Sub

Bei meinem Versuch erhalte ich die Meldung "Object erforderlich
LG

 

Hallo,

anbei mal ein auf die Schnelle geschnitztes Beispiel. Es ist natürlich keine Fehlerbehandlung drin.
Der Name der UserForm wird im Caption angezeigt.
Gruß Uwe

 

Vielleicht noch so viel zu diesem Thema:

Eigentlich ist hier eine Objektvariable nicht nötig, da es ja offensichtlich nur um die Übergabe des Namens des zuvor per Button auf Hide gesetzten UserForm geht. Da würde eine Stringvariable ebenfalls sein Werk verrichten.

Aber schaden tut es nicht. Es kann ja sein, dass man dann doch mal noch auf was anderes aus dem Userform in dieser Variable zugreifen will.

Gruß Uwe

 

Hallo,

offensichtlich habe ich deine Problemstellung anders verstanden als Uwe, denn Uwe verwendet, wenn auch indirekt, eine "globale" Variable in einem Modul, welche hier über eine Property bereitgestellt wird. Aber auch das sollte nicht erforderlich sein. Mein Beispielcode gehört im Prinzip in die Klassenmodule der Userforms, also ganz ohne globale Code.

Um eine passende Hilfestellung geben zu können, wäre es hilfreich, wenn du hier im Forum eine entsprechende vereinfachte Datei hochladen könntest. So ohne Kontext kann ich mit deinem Code leider nichts anfangen.

Knobbi38

 

Hi,

das geht auch ohne Variablen/Properties: benutze einfach die Tag-Eigenschaft des UFO1, in welche du beim Aufruf z.B. den Namen des aufrufenden UFO2 (oder irgendetwas anderes Aussagekräftiges) einträgst. Dann kannst du im UFO1 auf den Inhalt der Tag-Eigenschaft entsprechend zugreifen und ihn weiterverwenden - nach diesem Prinzip:

Code im aufrufenden UFO2 zum Eintrag in die Tag-Eigenschaft im UFO1:

Code:

' UFO2
Private Sub CommandButton1_Click()
    UFO1.Tag = Me.Name
    UFO1.Show
End Sub

Code im UFO1 zum Auslesen der Tag-Egenschaft:

Code:

' UFO1
Private Sub CommandButton1_Click()
    MsgBox UFO1.Tag '<== Zugriff auf Tag-Eigenschaft
End Sub

---

 

@Beverly

Klar könnte man das so machen, aber genau dafür gibt es die Properties und Methoden. Die Tag-Eigenschaft wird hier genauso wie eine Public Objekt-Variable verwendet und damit gibst die Vorteile von OOP praktisch auf; Objekt-Referenzen können so auch nicht gespeichert werden.
Die Tag-Eigenschaft verwende ich, wenn überhaupt, nur innerhalb eines Objekts, keinesfalls zur Kommunikation zwischen Objekten.

Sollte später einmal ein Refactoring anstehen, ist es außerdem nicht mehr so offensichtlich, wofür eigentlich die Tag-Eigenschaft verwendet wird. Da muss dann aufwendig im gesamten Projekt geprüft werden, wo und wie diese Tag-Eigenschaft angesprochen bzw. verwendet wird. Die Lesbarkeit vom Code wird jedenfalls dadurch nicht erhöht.

Knobbi38

 

Hallo Miteinander,

es gibt, so auch hier mehrere Wege die zum Ziel führen.

Jeder hat so seine Vorlieben.

Ich übergebe den Tag des jeweiligen Controls höchstens, auch wenn man da ein Objekt mitgeben kann, eher für zum Einsatzzweck des Controls zugehörige Werte/Bedingungen oder was auch immer Sinn macht zwecks Weiterverarbeitung.

Aber das ist eben mein Umgang mit so was. Was nicht heißen soll, dass es das Non plus Ultra ist.

Gruß Uwe

 

@knobbi,

genau für solche temporären Zwecke hat MS die Tag-Eigenschaft speziell für die Nutzung durch die Programmierer "erfunden" - unabhängig davon, ob sie im selben Objekt verwendet oder an andere Objekte übergeben werden.

Und was spätere Änderungen am Code betrifft: benutzt man generell "sprechende" Bezeichnungen und übersichtliche Kennzeichnungen und Kommentare im Code ist das Nachvollziehen genau so wenig ein Problem als wenn man mit Variablen joungliert. Zu viele Variablen machen einen Code außerdem erst Recht unübersichtlich, zumal man bei der Tag-Eigenschaft problemlos erkennen kann, auf welches Objekt sie sich bezieht.

Aber letztendlich ist das alles Ansichtssache - man kann die vorhandenen Möglichkeiten sinnvoll nutzen oder das Fahrrad jedesmal neu erfinden.

---

 

Hallo Uwe,

die Tag Eigenschaft hat durchaus seine Berechtigung, nur eben m.M.n. nicht für die Kommunikation zwischen verschiedenen Objekten. So angewendet entspricht sie dann einer public Member Variable, welche eher selten verwendet wird, weil damit gegen das Prinzip der Datenkapselung verstoßen wird.

Gruß Knobbi38

 

@Beverly

Nicht alles, was MS für VBA "erfunden" hat um ein wenig OOP hinzuzufügen, ist auch automatisch gut (siehe #14).

Klar, das ist schon richtig, aber an dem Namen kann man nicht erkennen, wofür sie verwendet wird und beim Refactoring werden Änderungen dadurch eher erschwert, denn vereinfacht.
Die Verwendung der Tag-Eigenschaft deutet darauf hin, dass man es sich etwas einfach gemacht hat, anstatt es "sauber" auszuprogrammieren. Das hat mit "das Fahrrad jedesmal neu erfinden" nicht viel zu tun. So etwas fällt einem dann später oft wieder auf die Füße.

Gruß Knobbi38

Siehe auch:
Encapsulation in Programming: A Beginner’s Guide - Stackify