Office: (Office 2003) Ein Feld soll gesperrt sein bis Bedingung erfüllt ist.

Mit VBA kenne ich mich nicht gut aus, darum bitte ich um Hilfe.
Das Feld "TrackSLJN" soll in einer neuen Zeile gesperrt sein bis, das Feld "SongLiedBezeichnung" Daten hat.
Das Formular beinhaltet ein Unterformular, das bereits gesperrt ist bis die selbe Bedingung erfüllt ist.
Dazu drei Code die dafür in Frage kommen.

Code:

Private Sub ActivateDeactivateOriginators()
On Error GoTo fehler

    If Nz(Me!SongLiedBezeichnung) = "" Then
        Me![205 – Interpret Name - Uf].Enabled = False
    Else
        Me![205 – Interpret Name - Uf].Enabled = True
        If Nz(Me!VorfilterInterpret_205_Select) <> "" Then
            If Nz(Me![205 – Interpret Name - Uf].Form.InterpretName205) = "" Then Me![205 – Interpret Name - Uf].Form.InterpretName205 = Me!VorfilterInterpret_205_Select
        End If
    End If

Exit Sub
fehler: MsgBox "Fehler " & Err.Number & ": " & Err.Description, , "Bitte Fehlernummer und Beschreibung an den Administrator melden"
End Sub

Code:

Private Sub Form_Current()
On Error GoTo fehler

    ActivateDeactivateOriginators

Exit Sub
fehler: MsgBox "Fehler " & Err.Number & ": " & Err.Description, , "Bitte Fehlernummer und Beschreibung an den Administrator melden"
End Sub

Code:

Private Sub SongLiedBezeichnung_AfterUpdate()
On Error GoTo fehler

    ActivateDeactivateOriginators

Exit Sub
fehler: MsgBox "Fehler " & Err.Number & ": " & Err.Description, , "Bitte Fehlernummer und Beschreibung an den Administrator melden"
End Sub

Den Ablauf dieser drei Prozeduren kenne ich nicht.
Ich vermute die Zeile "Me!TrackSLJN.Enabled = True" muß nach "Else" eingefügt werden. Nur wie genau das aussehen soll, ist mir unbekannt.
"Private Sub ActivateDeactivateOriginators()

On Error GoTo fehler

If Nz(Me!SongLiedBezeichnung) = "" Then
Me![205 – Interpret Name - Uf].Enabled = False
Else
Me!TrackSLJN.Enabled = True
Me![205 – Interpret Name - Uf].Enabled = True
If Nz(Me!VorfilterInterpret_205_Select) <> "" Then
If Nz(Me![205 – Interpret Name - Uf].Form.InterpretName205) = "" Then Me![205 – Interpret Name - Uf].Form.InterpretName205 = Me!VorfilterInterpret_205_Select
End If
End If

Exit Sub
fehler: MsgBox "Fehler " & Err.Number & ": " & Err.Description, , "Bitte Fehlernummer und Beschreibung an den Administrator melden"
End Sub"

 

Hallo,

Code:

Private Sub ActivateDeactivateOriginators()
On Error GoTo fehler

   If Nz(Me!SongLiedBezeichnung) = "" Then
       Me![205 – Interpret Name - Uf].Enabled = False
   Else
       Me![205 – Interpret Name - Uf].Enabled = True
       If Nz(Me!VorfilterInterpret_205_Select) <> "" Then
           If Nz(Me![205 – Interpret Name - Uf].Form.InterpretName205) = "" Then Me![205 – Interpret Name - Uf].Form.InterpretName205 = Me!VorfilterInterpret_205_Select
       End If
   End If
   Me!TrackSLJN.Enabled = Nz(Me!SongLiedBezeichnung, "") <> ""

Exit Sub
fehler: MsgBox "Fehler " & Err.Number & ": " & Err.Description, , "Bitte Fehlernummer und Beschreibung an den Administrator melden"
End Sub

Übrigens bevorzuge ich Postings, die mit „Hallo” beginnen und mit einer Abschiedsformel enden. Da fühle ich mich nicht so wie ein entmenschlichter Tippgeber...

Gruß
Doming

 

Hallo Doming,
Bitte entschuldige mein etwas zu trockenes Verhalten.
Deine Vorgabe fällt anders aus als von mir erwartet, aber es funktioniert. Habe ich in einer alten Kopie probiert. Geht sehr gut.
Vielen Dank!

 

Ohne VBA geht so etwas einfach mit der bedingten Formatierung. Als Ausdruck dann so etwas wie:

Code:

Länge(Nz([MyField];""))=0

Übrigens sind Feldnamen wie "205 – Interpret Name - Uf" ein NoGo und in Access nicht zu gebrauchen!!!

 

Hallo ...,
Bedingte Formatierung ist in meiner Accessversion für das Feld (JaNein) nicht aktiv.
Ich muß meine Formulare erkennen und die Sortierung soll stimmen.
Als Feldname verstehe ich die Bezeichnung im Entwurf einer Tabelle. Diese Bezeichnung "205 – Interpret Name - Uf" als Feldnamen gibt es bei mir nicht.

 

Den Feldtyp hast du nicht dokumentiert und eine FC kann es nur für ein Steuerelement geben, nicht für ein Feld.

Richtig, aber als Bezeichner für ein Steuerelement ebenso ungeeignet. Das solltest du unbedingt ändern!

Klar solltest du deine Formularnamen kennen, aber eine Sortierung ist eigentlich irrelevant. Der Formularname hat nichts mit der Benennung des Unterformuar-Steuerelements zu tun. Access vergibt hier einen Default-Namen für das Steuerelement, welcher anschließend im Designer geändert werden sollte, damit es später keine Probleme damit gibt. Das war schon immer ein Grund für schwer zu lokalisierende Fehler.

 

Hallo Knobbi38,

Was heißt FC? Ich kenne das nicht.

Du bezeichnest die Nennung des Formulars in VBA als Steuerelement. Wofür gibt es die eckige Klammer.


So sehen bei mir die Formularnamen aus. Die Zahl sorgt für die Sortierung und ich erkenne schnell welches Unterformular zum welchem Hauptformular gehört.
Ein Unterformular brauch doch auch eine Bezeichnung.
Ich verstehe nicht was dich daran stört. Sind es die Leerzeichen oder die Bindestriche.
Was meinst Du mit "Unterformuar-Steuerelement"?
Wo finde ich den "Default-Namen"?

 

Hallo,

"FC" ist die Abkürzung für die VBA Klasse FormatCondition, was in der Access GUI auf deutsch als "BedingteFormatierung" bezeichnet wird.

Nein, alle Steuerelemente haben eine eigene Bezeichnung (NAME - Eigenschaft), welche in der Entwurfsansicht im Eigenschaftenblatt eingegeben werden kann. Dort steht auch für das gerade ausgewählte Steuerelement der Typ des Steuerlements auf dt., u.a. auch für ein Unterfomular Steuerelement. Access vergibt hier beim Entwurf Defaultnamen, welcher dann zur besseren Lesbarkeit geändert werden sollt, z..B. nach gängigen Namenskonventionen. Beim Unterformular-Steuerelement wählt der Assistent von Access leider als Name immer den Namen des geladenen Unterformulars. Somit gibt es ein Formular und ein Steuerelement mit gleichen Namen, was in der Programmierung dann zu Problemen führt und Fehler produziert, welche nur sehr schwer erkennbar sind.

Das ist richtig, führt aber im weiteren Verlauf immer mal wieder zu Problemen. Es gilt die "Best Practice", gängige Namenskonventionen zu verwenden, Objekte einen "sprechenden" Bezeichner zu geben und keine Sonderzeichen zu Verwenden, mit Ausnahme des Unterstrichs. Üblicherweise wird hier Pascal Case genutzt, wobei die Präfixe dann meist klein geschrieben werden.

Du kannst natürlich nach dem Motto „Alles, was nicht verboten ist, ist erlaubt” verfahren, musst dann aber auch mit den daraus resultierenden Konsequenzen leben. Das bedeutet Schwierigkeiten beim Refactoring, unleserlichen und unverständlichen Code, Doppeldeutigkeit, einen erhöhten Aufwand beim Codeschreiben und nicht zuletzt immer wieder Probleme mit den SQL-Anweisungen – nicht umsonst heißt es „Best Practice”.

Vielleicht solltest du dir doch ein Fachbuch zum Thema Access zulegen, da die Vorgehensweise bei der Anwendungsentwicklung eine ganz andere ist als z. B. bei Excel. Ohne VBA kann man das Potenzial von Access gar nicht voll ausnutzen.

Nur mal eine kleine Auswahl:
https://www.rheinwerk-verlag.de/computer-office/microsoft-office/access/

Knobbi38

 

Hallo Knobbi38,
ich rätzel immer noch was Du als Steuerelement meinst.

Herkunftsobjekt ist eine Liste.


Hier könnte ich eine Änderung vornehmen, wenn Du das meinst. Und hier dann die Leerzeichen und Bindestriche entfernen.

Ich muß erst verstehen was wo wie gemeint ist, dann kann ich entscheiden wie ich damit umgehe.

Ich habe drei Fachbücher. Eins mit 873 Seiten aus 1995 angeschafft etwa 2001 ISBN 3-89360-324-7.
Oft habe ich mir gesagt, das Buch hat einen hohen Heizwert. Zwei Beispiele: Das es MN-Tabellen gibt und wann solche eingesetzt werden, war nicht erkennbar. Wie wichtig ein Kombinationsfeld ist und wann man es einsetzt, habe ich nicht erfahren. Ich halte diese Einstellung auf Kombinationsfeld für sehr wichtig. Erst auf Seite 394 und dann auf Seite 833 wird es kurz beschrieben.

 

Hallo,
vielleicht kann ich das mit den beiden Screenshots etwas verdeutlichen.
Im ersten Screenshot siehst du die Situation direkt nach dem Einfügen eines Unterformulars (sfmData). In den Eigenschaften und im Designer sind das Unterformularsteuerelement markiert, wie du unschwer am Auswahltyp erkennen kannst. Das Steuerelement selber hat den Namen sfrmData und das Unterformular ebenfalls, so wie es Access vorgibt und was ja nicht sein sollte.

Deshalb im zweiten Screenshot die Änderungen, so wie es eigentlich sein sollte, wo das Unterformularsteuerelement den Namen "subContainer" bekommen hat und das geladene Formular ist "sfmData". Ich habe hier mal die Präfixe "sub" und "sfm" verwendet.


Was die Bücher betrifft, haben die natürlich ihr Augenmerk auf verschiedene Themen. Was die Datenmodellierung betrifft, gibt es sicherlich sehr gute Online Tutorials und auch Bücher, z.B.:
A. Stern: Keine Angst vor Microsoft Access!

Wenn es um Access VBA geht, wird die Luft schön etwas dünner, aber ich schaue immer noch gerne in den Vorläufer von diesem Buch:
Access programmieren | Grundlagen und Praxiswissen | HANSER Fachbuch | 978-3-446-45027-1 | edv-buchversand.de

Knobbi38