Kontrollkästchen zurücksetzen

[Lalikowski]

Hallo zusammen,

ich möchte mehrere Kontrollkästchen wieder auf null setzen.

Meinte dass folgender code richtig sei:

chkBox_1.value = false
chkBox_2.value = false
                 .
                 .
                 .

Bekomme jedoch einen Kompilierfehler für .value....

Was mache ich falsch?

Viele Grüße

Andreas

[DF6GL]

Hallo,

Was mache ich falsch?

Das ".value" wegzulassen und "Me!" davor zu setzen...

Evtl. fehlt zudem "Option Explicit" im (in jedem) Formularmodul-Kopf.

[Lalikowski]

Hallo Franz,

lieben Dank für die schnelle Antwort, aber ich befürchte, dass ich damit nicht umgehen kann...:-(.

Das Zurücksetzen möchte ich über eine Schaltfläche realisieren.

Wenn ich in die Ereignisprozedur:

Me!chkBox_1 = False

bekomme ich einen Fehler.

Leider kann ich mit "Option Explicit" nichts anfangen. Wo muss das eingetragen werden?

Viele Grüße

Andreas Schmeier

[markusxy]

Das ".value" wegzulassen und "Me!" davor zu setzen...

Ich würde jetzt zum Gegenteil raten.
"Me!" davor, führt ja wieder dazu, dass Schreibfehler nicht gemeldet werden.
Entweder das "Me!" weglassen oder "Me." schreiben, dann meckert der Compiler wenigstens bei einem Fehler.
Das ".Value" entfernen - was könnte das denn bringen?

[MzKlMu]

Hallo,

bekomme ich einen Fehler.

das ist eine Aussage die völlig überflüssig ist, was soll man damit anfangen? Was für ein Fehler ? Bitte zitieren.

Option Explicit wird in jedem Modulkopf gesetzt und verhindert die Verwendung undeklarierter Variablen, was überaus sinnvoll ist.

Code [Auswählen] Erweitern

Option Compare Database
Option Explicit

[DF6GL]

Hallo,

solche grundlegenden Kenntnisse solltest Du Dir zunächst zu Gemüte führen...


Und: 
WIE lautet die Fehlermeldung?
WIE lautet der gesamte Code der Prozedur? (Copy&Paste)
WIE lautet der Name der Schaltfläche?

Wo muss das eingetragen werden?

Hatte ich geschrieben:  ..im (in jedem) Formularmodul-Kopf....

Code [Auswählen] Erweitern

Option Compare Database
Option Explicit
.
.
.

Private Sub btnMeineSchaltfläche_Click()
Me!chkBox_1 = False
End Sub

Gibt es ein (gebundenes)  Formular-Steuerelement (Kontollkästchen) mit Namen "chkbox_1" ?

[DF6GL]

Hallo,

Ich würde jetzt zum Gegenteil raten.

Das möchte ich nun wieder nicht unterschreiben...


Me wegzulassen ist eher Murks als dass es einen Vorteil hat. Über Me! und Me. kann man streiten, da gibt es auch die unterschiedlichsten Meinungen, und je nachdem, was man nun genau machen will. In der Tat kommt IntelliSense zum Tragen, wenn der Punkt verwendet wird.  Das ist durchaus manchmal von Vorteil.  Ich ändere aber in solchen Fällen den Punkt in ein "!", wenn man sich auf das Steuerelement (Control) und nicht auf die Form-Eigenschaft beziehen will.

Spätestens beim Zugriff auf Felder eines Recordsets gibt es dann Probleme.

Wenn die Fehlermeldung sich auf Value bezieht, dann lass ich value weg mit der realistischen Hoffnung, dass eine (in Verbindung mit Option Explicit) genauere Fehlermeldung erscheint.

Dies ist ein Vorschlag für den TS, nicht meine Vorgehensweise bei der Fehlersuche...
Zudem vermute ich, dass der anfangs gepostete "Code" nicht mit C&P hier eingestellt und eher händisch eingetippt wurde, was möglicherweise nicht dem Original entspricht.

[Josef P.]

[OT Me. vs. Me!]

Hallo!

Vorab:
Ich will jetzt keine Grundsatzdiskussion anstoßen, da das Thema hier OT ist. Ein paar Punkte will ich aber anmerken.

In der Tat kommt IntelliSense zum Tragen, wenn der Punkt verwendet wird.  Das ist durchaus manchmal von Vorteil.  Ich ändere aber in solchen Fällen den Punkt in ein "!", wenn man sich auf das Steuerelement (Control) und nicht auf die Form-Eigenschaft beziehen will.

Me.SteuerelementName ist eine Formulareigenschaft.
Me!SteuerelementName ist eine abgekürzte (und von Access zugriffsoptimierte) Schreibweise von Me.Controls("SteuerelementName")

Das Problem von Me. bei Zugriff auf Datenfelder kenne ich im Zusammenhang von Änderung der Datenquelle.
Ich selbst verwende einen Steuerelementnamen der vom Datenquellnamen abweicht, sobald ich per VBA auf das Steuerelement zugreifen will. Das hat den Vorteil, dass der Compiler meckert, wenn ich ein Steuerelement lösche und im Code darauf Bezug genommen wird.
Auf Datenfelder (AccessField) greife ich per Me!Datenfeldname zu. Das aber gar nicht so wegen dem möglichen Eigenschaftsproblem sondern wegen der Lesbarkeit des Codes.
Me.txtVorname => ich weiß, dass das die Textbox mit dem Vornamen ist.
Me!Vorname => ich weiß, dass das der direkte Zugriff auf das AccessField ist.

Spätestens beim Zugriff auf Felder eines Recordsets gibt es dann Probleme.

Auf Felder des Recordsets greifst du mit FormRef!xxxx nicht direkt zu. Du greifst immer auf die Elemente der Control-Auflistung zu. Diese kann Control- und AccessField-Referenzen enthalten.
Indirekt kommen damit natürlich die Daten aus dem Formular-Recordset aber die Referenz verweist auf kein DAO/ADODB.Field-Objekt.

Nach meiner Erfahrung kommt das Problem bei Änderungen der Datenquelle zur Laufzeit. Ich kann aber gar nicht sagen, ob das Problem immer noch vorhanden ist oder es nur in Access 2003 und früher exisitierte. (Dieses Problem nachzustellen, ist nämlich gar nichts so einfach.)
Eines kann ich aber bestätigen: seit mehr als 15 Jahren, seit ich die oben geschilderte Me.txtVorname/Me!Vorname-Systematik verwende, hatte ich nie mehr Probleme mit me.SteuerelementName.

Mögliche Problemursache (leider lässt sich das Problem nur bedingt nachstellen):
Im Formularentwurf wird bei Änderung der Datenquelle für jedes Datenfeld eine AccessField-Eigenschaft erstellt, welche wiederum durch eine Control-Eigenschaft (z. B. Textbox-Objekt) überschrieben wird, wenn das Steuerelement und das Datenfeld den gleichen Namen haben. Hat man kein Steuerelement, wird die Eigenschaft des AccessField kompiliert. Wird dann zu Laufzeit die Datenquelle geändert, dass dieses AccessField nicht mehr verfügbar ist, kann es zu einem Laufzeitfehler kommen - und zwar nicht erst beim direkten Zugriff auf das Datenfeld (hier würde spätestens auch Me! zu einem Fehler führen).

mfg
Josef

[DF6GL]

Hallo,

auch OT 


Ich für mich  habe mir angewöhnt, gebundene Controls gleich wie das zugrunde liegende Feld zu benennen. Das hilft mir, meine Denk- und Suchfaulheit zu pflegen.  Ist dagegen ein Control (z. B.  ein Textfeld) bezgl. der Datenherkunft  ungebunden, erhält es in diesem Fall den Prefix "txt" vorangestellt.  Grundsätzlich nutze ich für die Referenz auf ein Control das "!" als eben die genannte Abkürzung auf den ControlObjekt(-namen), was mir zweckdienlich zur Unterscheidung zu Form-Eigenschaften erscheint.


Es gibt nichts Schlimmeres, als in einer (fremden) Datenbank mit zu den Datenherkunft- Feldern unterschiedlich benannten Controls Fehlersuche zu betreiben, vor allem, wenn die ganze Benamsung keinen Notationsprinzipien folgt. 

Bis auf einen (älteren) Fall mit einer Vorgängerversion (und da auch nur in einem Bericht, in dem ein Control gelöscht wurde, aber anschließend wieder eingefügt und gebunden wurde)  habe ich nie Probleme mit der "!" -Referenz erlebt.

Wie vorher schon gesagt, benutze ich den Punkt (in Bezug auf Control-Referenz) nur dann, wenn der Control-Name unbekannt, bzw. vergessen (  ) ist und  mir IntelliSense hilft, ihn zu finden.     Danach ändere ich ihn aber trotzdem in "!" .



Hoffentlich ist der TS jetzt nicht vergrämt und meldet sich nochmal, vielleicht auch mit einem C&P des beanstandeten Codes..