AfterUpdate nach SetzenWert

[Michael Alexander]

Hallo NG!

Ich setze mittels VBA in einem Feld einen bestimmten Wert ein. Danch wird
aber das AfterUpdate-Ereignis nicht ausgelöst, sondern nur bei manueller
Eingabe. Geht das auch anders als mittels
Call MeinFeld_AfterUpdate?

Danke
Michael

A2k, SP3

[Jens Schilling]

Hallo, Michael

> Ich setze mittels VBA in einem Feld einen bestimmten Wert ein. Danch
> wird aber das AfterUpdate-Ereignis nicht ausgelöst, sondern nur bei
> manueller Eingabe. Geht das auch anders als mittels
> Call MeinFeld_AfterUpdate?

Um das Event auszulösen solltest Du den Wert nicht direkt dem Steuerelement
zuzuweisen, sondern statt dessen seiner Eigenschaft < Text >; dies löst dann
auch das AfterUpdate-Event aus.

--
Gruss
Jens
______________________________
1. SEK (SQL Server-Entwickler-Konferenz)
Nürnberg, Sa/So 21./22.4.2007 (ausgebucht)
FAQ: http://www.donkarl.com

[Michael Alexander]

Hallo Jens!

"Jens Schilling" <jensschilling...@fissership.de> schrieb im
Newsbeitrag news:%23ZyUAkZ...@TK2MSFTNGP02.phx.gbl...

> Hallo, Michael
>
>> Ich setze mittels VBA in einem Feld einen bestimmten Wert ein. Danch
>> wird aber das AfterUpdate-Ereignis nicht ausgelöst, sondern nur bei
>> manueller Eingabe. Geht das auch anders als mittels
>> Call MeinFeld_AfterUpdate?
>
> Um das Event auszulösen solltest Du den Wert nicht direkt dem
> Steuerelement zuzuweisen, sondern statt dessen seiner Eigenschaft < Text
> >; dies löst dann auch das AfterUpdate-Event aus.

Meintest Du Me.Meinfeld.Text=Wert ?

Dann bekomme ich die Fehlermeldung: "Sie können die Eigenschaften oder
Methoden eines Steuerelements nur dann auswerten, wenn es den Fokus hat."

Ansonsten habe ich leider nicht verstanden, wie Du das meinst.

Danke
Michael

[Jens Schilling]

Hallo, Michael

>>> Ich setze mittels VBA in einem Feld einen bestimmten Wert ein. Danch
>>> wird aber das AfterUpdate-Ereignis nicht ausgelöst, sondern nur bei
>>> manueller Eingabe. Geht das auch anders als mittels
>>> Call MeinFeld_AfterUpdate?
>>
>> Um das Event auszulösen solltest Du den Wert nicht direkt dem
>> Steuerelement zuzuweisen, sondern statt dessen seiner Eigenschaft <
>> Text >; dies löst dann auch das AfterUpdate-Event aus.
>
> Meintest Du Me.Meinfeld.Text=Wert ?

Ja...

> Dann bekomme ich die Fehlermeldung: "Sie können die Eigenschaften oder
> Methoden eines Steuerelements nur dann auswerten, wenn es den Fokus
> hat." Ansonsten habe ich leider nicht verstanden, wie Du das meinst.

Du hast mich schon richtig verstanden, dann setze eben vorher den Fokus auf
das Feld.

[Stefan Dase]

Hallo Michael,

> Ich setze mittels VBA in einem Feld einen bestimmten Wert ein. Danch wird
> aber das AfterUpdate-Ereignis nicht ausgelöst, sondern nur bei manueller
> Eingabe. Geht das auch anders als mittels
> Call MeinFeld_AfterUpdate?

Ich persönlich verwende den von Jens beschriebenen Weg nie, sondern rufe
sowohl im AfterUpdate-Ereignis als auch an gewünschter anderer Stelle
jeweils eine Private Function/Sub im Modul mittels Call auf.

Im übrigen funktioniert auch Call MeinFeld_AfterUpdate.

Viele Grüße,
Stefan

[Jens Schilling]

Hallo, Stefan

>> Ich setze mittels VBA in einem Feld einen bestimmten Wert ein. Danch
>> wird aber das AfterUpdate-Ereignis nicht ausgelöst, sondern nur bei
>> manueller Eingabe. Geht das auch anders als mittels
>> Call MeinFeld_AfterUpdate?
>
> Ich persönlich verwende den von Jens beschriebenen Weg nie, sondern
> rufe sowohl im AfterUpdate-Ereignis als auch an gewünschter anderer
> Stelle jeweils eine Private Function/Sub im Modul mittels Call auf.

Gibt es einen Grund dafür, es nicht zu tun ?
Wenn ich wirklich nur das AfterUpdate des betroffenden Feldes auslösen
möchte, sehe ich nichts, was dagegen spräche.

[Michael Alexander]

Hallo Jens!
Danke, er klappt!

Gruß
Michael

"Jens Schilling" <jensschilling...@fissership.de> schrieb im

Newsbeitrag news:%23xtkYCb...@TK2MSFTNGP06.phx.gbl...

[Stefan Dase]

Hallo Jens,

>>> Ich setze mittels VBA in einem Feld einen bestimmten Wert ein. Danch
>>> wird aber das AfterUpdate-Ereignis nicht ausgelöst, sondern nur bei
>>> manueller Eingabe. Geht das auch anders als mittels
>>> Call MeinFeld_AfterUpdate?
>> Ich persönlich verwende den von Jens beschriebenen Weg nie, sondern
>> rufe sowohl im AfterUpdate-Ereignis als auch an gewünschter anderer
>> Stelle jeweils eine Private Function/Sub im Modul mittels Call auf.
>
> Gibt es einen Grund dafür, es nicht zu tun ?
> Wenn ich wirklich nur das AfterUpdate des betroffenden Feldes auslösen
> möchte, sehe ich nichts, was dagegen spräche.

Außer, dass die Text-Eigenschaft es erfordert, dass das Feld den Fokus
hat, gibt es nichts, was aus meiner Sicht gegen deinen Ansatz spricht.

Ich halte nur gerne Funktionen, die an mehreren Stellen verwendet
werden, aus den Event-Handlern raus. Wenn sie als Public deklariert
sind, können sie dann sogar von anderen Objekten aus verwendet werden.

Viele Grüße,
Stefan

[Henry Habermacher [MVP Access]]

Hallo Michael

quoting Michael Alexander:
> Ich setze mittels VBA in einem Feld einen bestimmten Wert ein. Danch
> wird aber das AfterUpdate-Ereignis nicht ausgelöst, sondern nur bei
> manueller Eingabe. Geht das auch anders als mittels
> Call MeinFeld_AfterUpdate?

Nebst dem Ansatz den Jens schon genannt hat (und für mich in einen ähnlichen
Bereich wie Pfui-Sendkeys geht) ist Dein genanntes Vorgehen eigentlich schon
der Weg, wie das üblicherweise gemacht wird. Du kannst auch den Code im
AfterUpdate Ereignis in eine Funktion legen und dann diese sowohl in der
"Nach Aktualsierung" Eigenschaft direkt aufrufen, indem Du =DeineFunktion()
einträgst. Die gleiche Funktion rufst Du dann eben auch auf, wenn Du per
Code den Inhalt des Controls geändert hast oder z.B. beim Form_BeforeUpdate.

Gruss
Henry

--
Keine E-Mails auf Postings in NGs. Danke.
KB: http://support.microsoft.com/default.aspx
FAQ: http://www.donkarl.com
OH: Online Hilfe (Taste F1)
Downloads: http://www.dbdev.org

[Henry Habermacher [MVP Access]]

Hallo Jens

quoting Jens Schilling:
> Gibt es einen Grund dafür, es nicht zu tun ?
> Wenn ich wirklich nur das AfterUpdate des betroffenden Feldes auslösen
> möchte, sehe ich nichts, was dagegen spräche.

Was dagegen spricht ist das Rumgehüpfe auf dem Formular, per VBA sollte
sowas nicht notwendig sein, um Daten in einen virtuellen Datensatz
einzufügen und aktionen auszulösen. Rumhüpfen auf dem Formular beeinflusst
die Präsentation. Aus einem bestimmten Grund ist der Focus ja nicht auf
diesem Feld, das Du veränderst und müsstest den anschliessend wieder
zurücksetzen, wo er ursprünglich war, unter Berücksichtigung der nun weiter
getriggerten Events, wie LostFocus, etc.

Mir persönlich gefällt es nicht, wenn ich die Präsentation der Daten dazu
missbrauche, Ereignisse abzufeuern, welche ich per VBA einfach auslösen
kann. Kommt hinzu, dass das Rumgehüpfe durchaus für den Benutzer sichtbar
wird, abhängig davon, wie lange es geht und was da alles gemacht wird.

[Jens Schilling]

Hallo, Henry

> Nebst dem Ansatz den Jens schon genannt hat (und für mich in einen
> ähnlichen Bereich wie Pfui-Sendkeys geht)

Kannst Du mir sagen warum ?

Das Verhalten ist schon für A2 in der KB (
http://support.microsoft.com/kb/504256/de ) dokumentitiert, und Probleme
habe ich damit bisher nicht erlebt - und auch noch davon gehört oder
gelesen.

[Jens Schilling]

Hallo, Henry

> Mir persönlich gefällt es nicht,

OK - also Geschmackssache ...

>wenn ich die Präsentation der Daten
> dazu missbrauche, Ereignisse abzufeuern, welche ich per VBA einfach
> auslösen kann.

Die Methode löst ebenfalls ein Event per VBA aus ;-)

>Kommt hinzu, dass das Rumgehüpfe durchaus für den
> Benutzer sichtbar wird,

Application.Echo False
....
Application.Echo True
;-)

Deine Bedenken, dass andere Events ins Spiel kommen könnten, wären ein
stichhaltiges Argument, aber das weiss ich ja als Entwickler.

Ich sehe diese Methode auch nicht als Allheilmittel - aber wir haben
kürzlich hier z.B. einen Thread gehabt, in dem per (Barcode-?) Scanner
Daten in ein Textfeld geschrieben wurde, und das AfterUpdate-Event sollte
lediglich ein Me.Dirty = False auslösen; da halte ich das z.B. für durchaus
angebracht.

[Henry Habermacher [MVP Access]]

Hallo Jens

quoting Jens Schilling:
>> Nebst dem Ansatz den Jens schon genannt hat (und für mich in einen
>> ähnlichen Bereich wie Pfui-Sendkeys geht)
>
> Kannst Du mir sagen warum ?
>
> Das Verhalten ist schon für A2 in der KB (
> http://support.microsoft.com/kb/504256/de ) dokumentitiert, und
> Probleme habe ich damit bisher nicht erlebt - und auch noch davon
> gehört oder gelesen.

Ist halt Geschmacksache oder Purismus. Pfui-Sendkey ist auch in der KB und
in der OH beschrieben, was nicht heisst, dass es zur guten Praxis gehört.
Ganz so schlimm finde ich aber Dein Vorgehen nicht. Mich stört einfach das
Rumgehüpfe zum Zweck der Event Auslösung. Das ist ein "Missbrauch" der
Präsentationsschicht der Anwendung zum Aufrufen von Code in einer
Ereignisprozedur, der ohne die Präsentationsschicht zu bemühen direkt per
VBA aufgerufen werden kann.

Du machst etwa folgendes:

1. Focus auf Feld Setzen
-> Präsentation checkt, welche Events abgefeuert werden müssen. Es könnte
durchaus jetzt schon zum Abfeuern von LostFocus und GotFocus Ereignissen
kommen

2. Text Eigenschaft ändern
-> Präsentation checkt welche Events abgefeuert werden müssen, z.B. der
Dirty Event

3. Focus wieder sonstwohin setzen oder Me.Dirty = False setzen
-> Präsentation checkt erneut und feuert nun den Control_AfterUpdate Event
ab

4. Nun wird endlich der Code:
MsgBox "Feldinhalt hat geändert"
aufgerufen und die gwünschte MsgBox popt auf. Beep!

So, nun der Direktaufruf über:
Call MeinControl_AfterUpdate()

1. Der VBA Interpreter verzweigt zum Code der aufgerufenen Prozedur, die
MsgBox popt auf.

Entscheide nun selber, was besser ist.

Ach ja, bezüglich Pfui-Sendkeys:
Hier würde es so gehen:
1. identisch
2. SendKeys ....
3. identisch
4. identisch

Ausser dass Du die Text Eigenschaft mit einem String füllst, machst Du da
nur noch einen klitzekleinen Umweg über Sendkeys, von dem Du die Literale
Buchstabenweise in das Feld abfüllen lässt. Ein grosser Unterschied ist da
nicht mehr vorhanden, ausser dass SendKeys überhaupt aufgerufen wird und
allenfalls noch KeyDown, etc. Ereignisse abgefeuert würden (habe ich nicht
verifiziert).

[Henry Habermacher [MVP Access]]

Hallo Jens

quoting Jens Schilling:
>> wenn ich die Präsentation der Daten
>> dazu missbrauche, Ereignisse abzufeuern, welche ich per VBA einfach
>> auslösen kann.
>
> Die Methode löst ebenfalls ein Event per VBA aus ;-)

Nein, werden beim Direktaufruf nicht!

>> Kommt hinzu, dass das Rumgehüpfe durchaus für den
>> Benutzer sichtbar wird,
>
> Application.Echo False
> ....
> Application.Echo True
> ;-)

Ohne Smiley hätte ich nun tatsächlich die Raison verloren...

> Deine Bedenken, dass andere Events ins Spiel kommen könnten, wären ein
> stichhaltiges Argument, aber das weiss ich ja als Entwickler.

So?!? Weisst Du wirklich wo überall noch irgendwelcher VBA Code dann noch
Text in das Ereignis reinschreibt und nicht davon ausgeht, dass da dann noch
der Event abgefeuert wird, den Du gerade am ausprogramieren bist? Ich
behaupte schlicht und einfach, das ist gar nicht möglich, das dann immer
noch voll im Auge zu behalten und darum versuche ich, wenn's immer geht,
solche Side-Effekte im Vornherein gar nicht entstehen zu lassen. Schon
vergessen? Wie schreibe ich fehlerlosen Code? ;-)

> Ich sehe diese Methode auch nicht als Allheilmittel - aber wir haben
> kürzlich hier z.B. einen Thread gehabt, in dem per (Barcode-?) Scanner
> Daten in ein Textfeld geschrieben wurde, und das AfterUpdate-Event
> sollte lediglich ein Me.Dirty = False auslösen; da halte ich das z.B.
> für durchaus angebracht.

Der Barcode Scaner ist eine Pseudo-Tastatur, die anschliessend noch zweimal
Enter drückt und kein VBA Code. Ein Barcode Scaner kann sozusagen nur
Pfui-SendKeys ausführen, aber das heisst nicht, dass das saubere Praxis ist.
Geht einfach einfacher so mit der Integration in bestehende Anwendungen.
Sauber wäre, wenn eine Barcodescaner Klasse in der Anwendung instanziiert
würde, welche sich für den Scaned Event registriert und dann, wenn der
Scaner diesen Event auslöst, entsprechend den Wert in das Feld auf dem
Formular schreibt. Nur haben Barcode Scaner in der Regel kein solches API
verfügbar. Wir haben das aber in Access, wieso also der Umweg über die
Präsentation?

[Jens Schilling]

Hallo, Henry

>>> Nebst dem Ansatz den Jens schon genannt hat (und für mich in einen
>>> ähnlichen Bereich wie Pfui-Sendkeys geht)

> Ganz so schlimm finde ich aber Dein Vorgehen nicht.

Nach diesem versöhnlichen Satz können wir das Thema auch abschliessen ;-)

Tschüs
Jens

[Jens Schilling]

Hallo, Henry

>> Application.Echo True
>> ;-)
> Ohne Smiley hätte ich nun tatsächlich die Raison verloren...

Ja - man muss wissen, wo so ein kleines Kerlchen *unbedingt* hingehört ;-)

Tschüs
Jens