Eingabe in Steuerelement

Question

Hallo zusammen,

In meiner Acc-XP Anwendung ändere ich über ein Steuerelement [KdNr] eine vorhandene Kundennummer.

Die Datenherkunft für das Form ist eine Abfrage.

Nun möchte ich, dass bei einer Änderung, also beim Überschreiben einer KundenNr diese sofort gespeichert wird.

Ich habe dazu im Ereignis [Bei Änderung] eingefügt: "IF Me.Dirty Then ME.Dirty = False"

Damit funktioniert zwar das Speichern, allerdings zeigt sich ein ganz eigenartiges Phänomen. Bei der Eingabe von 123, wird von rechts nach links aufgefüllt mit dem Ergebnis 321

 

Ich würde mich freuen wenn ich hier einen Tipp, eine Erklärung, bzw. eine Lösung bekommen würde.

 

Vielen Dank

Richard

Answer 1

Hallo,

Hölzel Richard wrote:

In meiner Acc-XP Anwendung ändere ich über ein Steuerelement [KdNr] eine
vorhandene Kundennummer.

Nun möchte ich, dass bei einer Änderung, also beim Überschreiben einer
KundenNr diese sofort gespeichert wird.

Ich habe dazu im Ereignis [Bei Änderung] eingefügt: "*IF Me.Dirty Then
ME.Dirty = False*"

Das Ereignis "Bei Aenderung" (On Change) tritt nach der Eingabe jedes
einzelnen Zeichens ein. Das ist sicher nicht, was du willst, oder? Wenn du
nach der Eingabe der kompletten Kundennummer speichern willst, mach das im
Ereignis "Nach Aktualisierung" (After Update) des Feldes. Damit duerfte
sich auch das seltsame Verhalten bez. 123->321 erledigen.

Gruss - Peter

---

Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com

Answer 2

Hallo Peter,

danke für Deine schnelle Antwort.

Mit Deiner Lösung wird zwar die Eingabe korrekt dargestellt, aber gespeichert wird erst (After Update), über IF Me.Dirty Then ME.Dirty = False  wenn die Eingabe beendet ist und das Feld verlassen wird.

Bei meiner Lösung (Bei Änderung) wird mit IF Me.Dirty Then ME.Dirty = False nach jeder Eingabe, d.h. z.B. nach Eingabe 1.Zahl, dann 2.Zahl danach 3.Zahl, jeweils gespeichert und der dazugehörige Kundenname angezeigt. Nur dass eben das eigenartige Verhalten 123 wird zu 321 auftritt.

 Gibt es dafür eine Erklärung?

Besten Dank

Richard

Answer 3

Hallo,

Hölzel Richard wrote:

Mit Deiner Lösung wird zwar die Eingabe korrekt dargestellt, aber
gespeichert wird erst (After Update), über*IF Me.Dirty Then ME.Dirty =
False* wenn die Eingabe beendet ist und das Feld verlassen wird.

Das liest sich, als waerest du nicht versehentlich ins Change-Ereignis
geraten, sondern wolltest tatsaechlich nach jedem Zeichen speichern. Warum?

Dadurch kannst du lustige Konstellationen bekommen, z.B. dass ein anderer
Benutzer dein Zwischenergebnis liest und verarbeitet.

Bei meiner Lösung (Bei Änderung) wird mit*IF Me.Dirty Then ME.Dirty =
False* nach jeder Eingabe, d.h. z.B. nach Eingabe 1.Zahl, dann 2.Zahl
danach 3.Zahl, jeweils gespeichert und der dazugehörige Kundenname
angezeigt. Nur dass eben das eigenartige Verhalten 123 wird zu 321
auftritt.

 Gibt es dafür eine Erklärung?

Ich hab keine. Bei mir wird genau das gespeichert, was ich eingebe. Ich
koennte mir vorstellen, dass da noch weiterer Code laeuft, den du hier noch
nicht erwaehnt hast. Gibt es weitere Ereignisse im Formular, also nicht nur
fuer dieses Steuerelement, sondern auch Formularereignisse? Denn wegen des
Dirty=False wuerde die gesamte Ereigniskette einschl. Vor/Nach
Aktualisierung des Formulars durchlaufen, sofern vorhanden.

Gruss - Peter

---

Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com

Answer 4

Hallo Richard,

ich vermute, dass durch die Ereignisprozedur der Cursor im Steuerelement immer wieder an den Anfang des Feldes gesetzt wird. Also du Tippst die 1, die Ereignisprozedur läuft, der Cursor springt wieder an den Anfang und damit wird die 2 dann VOR der 1 und nicht nach der 1 erfasst.

 

Gruß

Dirk

Answer 5

Hallo,

 

just.do.it wrote:

 

> ich vermute, dass durch die Ereignisprozedur der Cursor im Steuerelement

> immer wieder an den Anfang des Feldes gesetzt wird. Also du Tippst die

> 1, die Ereignisprozedur läuft, der Cursor springt wieder an den Anfang

> und damit wird die 2 dann VOR der 1 und nicht nach der 1 erfasst.

 

Bei meinem Test war das nicht der Fall, deshalb meine Rueckfrage nach

anderen potentiellen Prozeduren.

 

Gruss - Peter

 

--

Mitglied im http://www.dbdev.org

FAQ: http://www.donkarl.com

 

Answer 6

Hallo zusammen,

erstmal besten Dank an Peter und just.do.it

Der Beitrag von " just.do.it" hat mir glaube ich den richtigen Denkanstoss gegeben. Aber auch Peter hat mich auf den richtigen Weg geführt. Danke!

Ich habe jetzt mal den Ändern-Ereignis (On Change) bei "IF Me.Dirty Then ME.Dirty = False" einen Haltepunkt gesetzt.

Dabei sieht man, nach der Eingabe der ersten Zahl, z.B. 1

-         wird "IF Me.Dirty…."  ausgeführt,

-         und der Datensatz wird gespeichert

-         danach wird der Cursor vor die eingegeben 1 gesetzt

-         bei der nächsten Eingabe z.B. 2

-         wird wieder "IF Me.Dirty…."  ausgeführt

-         und die eingegeben 2 steht vor der ersten Eingabe (1)

Damit ist das "seltsame Verhalten" bei der Eingabe verstanden und mein Ziel die Eingaben ohne verlassen des Eingabefeldes (also Bei Änderung) zu aktualisieren, kann so nicht realisiert werden.

Als Lösung könnte ich mir vorstellen, nach jeder Eingabe den Cursor nach hinten setzen, so dass die Eingabe ohne das Eingabefeld zu verlassen korrekt übernommen wird.

Aber, Frage: ist so etwas überhaupt möglich?

 

Auf alle Fälle sage ich schon mal Danke, für die guten Anregungen

-         Noch ein Hinweis für Peter:

In dem Form gibt nur das (On Change) Ereignis

 

Gruss Richard

Answer 7

Als Lösung könnte ich mir vorstellen, nach jeder Eingabe den Cursor nach hinten setzen, so dass die Eingabe ohne das Eingabefeld zu verlassen korrekt übernommen wird. 

Aber, Frage: ist so etwas überhaupt möglich?

Ja, schon, siehe http://www.donkarl.com?FAQ4.24 und da "Cursor an das Ende des Textes".

Gruss - Peter

 

Answer 8

Hallo Peter

Peter Doering [MVP] wrote:

Das liest sich, als waerest du nicht versehentlich ins Change-Ereignis
geraten, sondern wolltest tatsaechlich nach jedem Zeichen speichern.
Warum?

Dadurch kannst du lustige Konstellationen bekommen, z.B. dass ein anderer
Benutzer dein Zwischenergebnis liest und verarbeitet.

Nicht nur das: Wenn der eine Kunde dann z.B. 123 hat und er den Kunden 1234 erfasst, wird nach dem 3. Zeichen eine Schlüsselverletzung auftreten, es sei denn, das Datenmodell ist nicht ganz sauber und erlaubt verschiedene Kunden mit der gleichen Kunden Nummer...

Gruss
Henry