Office: (Office 2013) VBA. Button Entwurfsansicht/Formularansicht abfragen ob gedrückt wurde

Also ohne dir auf die Füße treten zu wollen... Aber mit dem Lesen .. "Wer im Glashaus sitzt...." Es wäre dir dann aufgefallen, dass ich den Link schon viel früher vor dir gepostet habe.

Und auch wenn du Post #41 von mir gelesen hättest, wüsstest du das mir der Link nix bringt da eben NICHT die Ereignisse, wie auf der Seite von MS beschrieben, ein für alle Mal festgelegt sind.

Und jetzt habe ich mir extra mal die Mühe gemacht und eine Exceltabelle und eine TestDB die du am Ende findest erstellt. Ich habe dort die wichtigsten Ereignisse aufgenommen. Ich habe jeweils im Ereignis Form_Open, Form_Load, Form_Current folgenden Code untergebracht und Auskommentiert:

DoCmd.GoToRecord , , acNewRec

Und ich will nicht hören, dass es Sin-befreit ist, dass dieser Code in ein bestimmtes Ereignis gehört. Dies ist nur dazu da, um zu zeigen, dass Code den gesamten "festgenagelten" Ablauf durcheinander bringt. Und man als Anfänger dann doch durcheinander kommt.


Testablauf:

Einfach DB starten, Exceltabelle öffnen, "frm_ProdukteGruppenUndProdukte" doppelklicken und Reihenfolge mit Exceltabelle Spalte A vergleichen. Formular schließen, Editor öffnen Code bei Form_Open "scharf machen" Formular öffnen und mit Tabelle Spalte B vergleichen. Formular schließen, Editor öffnen Code auskommentieren und Code bei Form_Load "scharf machen" usw.

Wer sich das dann anschaut, soll´s mir bitte erklären, weil ich versteh´s nicht. Entweder er ist nun festgenagelt oder nicht. Oder ich hab ein komisches Access.

**************************************************************

******************************************************

Hm hört sich interessant an, können wir das per PN klären oder ich mache dafür ein neues Thema auf, oder schickst mir erstmal ein oder 2 Links zum Einlesen? Wenn wir hier damit auch noch anfangen in dem Thread blick ich sonst gar nimmer durch. Sind mittlerweile schon zig Themen die parallel hier laufen ^^

Und echt Danke für den Rest von deinem Post. *hands Ich dachte echt schon das alle hier noch nie Anfänger waren, und nur ich Probleme habe mit Access und VBA ^^

************************************************************

Musst du mir bitte auch mal bei Gelegenheit per PN erklären oder eben auch hier ein neuer Thread. Ich kann mich leider nicht zerteilen. Bevor ich jetzt wieder was Neues dazu nehme muss erstmal der Altbalast weg und laufen

Ich versuche die Formulare so einfach wie möglich zu halten. Je nach Erfahrung dessen, der die Daten eingibt. Es gibt DAU´s, bei denen wenn mehr als nur 1 Button im Formular vorhanden ist, schon überfordert sind.

Also ich mache lieber 20 Formulare die auf den jeweiligen User zugeschnitten sind, als 1 oder 2 um dann ständig Sachen anpassen muss, weil der eine damit nicht klarkommt.

Stell dir halt ein ganz einfaches Formular mit Unterformular vor. Ein Steuerelement aus der Mastertabelle im HFO und 2 Steuerelemente aus der Untertabelle im UFO (Oder du nimmst aus dem Anhang die DB her dort ist so´n einfaches Formular an dem noch nix gemacht wurde)

Ziel sollte es sein das Formular so weit zu automatisieren, das der User außer diesem Formular gar nix hat. Keine Ribbons, Kein Kontextmenü, keine Navileiste, Tasten nur "Tab"; "Enter". Die Tasten "links/rechts" gehen auch nur innerhalb eines Steuerelements"; "Esc". Sonst gibt’s keine Taste usw. Außerdem ist die Reihenfolge vorgegeben (Schon durch Access) 1. Steuerelement HFO Mastertabelle -> Daten Eingeben -> "Enter" oder "Tab" -> 1. Steuerelement UFO Untertabelle -> Daten eingeben -> "Enter" oder "Tab" (bei leerem Feld Hinweis, dass dies ausgefüllt werden muss) -> 2. Steuerelement UFO Untertabelle -> Daten eingeben -> "Enter" oder "Tab" -> (bei leerem Feld Hinweis, dass dies ausgefüllt werden muss) -> Und jetzt kommt das was ich meinte mit automatisch:

Beim Verlassen des letztmöglichen Feldes im Formular soll dann eine MsgBox oder was auch immer kommen wo dann gefragt wird, ob gespeichert oder abgebrochen werden soll. Speichern -> Neuer leerer DS. / Abbrechen Fokus ins erste Feld zum Korrigieren. So meinte ich mit automatisch. Nicht einen Button zum Speichern.


******************************************

Außerdem ist das Meiste Mittlerweile eh hinfällig, weil ich jetzt mir einen Kollegen ins Boot geholt habe, der zwar kein VBA kann, aber dennoch schon Erfahrung mit DB hat. Der weiß beim Eingeben, was er machen darf und was nicht. Dem reicht so´n ganz einfaches Formular ohne Bunt und Schnickschnack.
Und ist er mal nicht da, dann mach ich halt mal ne Stunde DB Datenklopfer.
Und für Mitte/Ende August. Kommen dann die Profis. Und dann hoff ich, dass meine DB vernichtet wird. (Ich hoff nur dass man aus der DB wenigstens die Daten rausholen kann und ich da nicht zu viel Mist gebaut hab *grins)
Ich werde zwar weiterhin an meinem von der allerersten Stunde daheim ausgedachten Minibeispiel experimentieren, aber das Ganze, hat jetzt etwas weniger Prio.


*******************************
Und @ Alle nicht nur @ drambeldier

Hier sind die Exceltabelle und die TestDB. Schaut´s euch an (Beschreibung siehe oben "Testablauf" oder im Editor im HFO der DB) und sagt mir was da los ist. Bitte

 

Dann muss ich mein Statement ergänzen: Posten reicht nicht, wenn man nicht vorher liest und zu verstehen versucht.

Mein Rat: Gib auf. Niemand will zuschauen, wie Du Dich verrennst. Jeder hat erstmal Probleme, der mit Ereignissen anfängt; niemand aber hat es jemals für nötig befunden, Access-eigene Ereignisketten "abzufangen". Setz Dich auf den Hosenboden und überdenke Dein Vorgehen.

 

Hallo,

Nicht nötig denke ich, ist schnell erklärt.
In der Entwurfsansicht auf dem Reiter Ereignisse siehst du ja alle
vorhandenen Ereignisse. Um nun Code in der zugehörigen Prozedur
auszuführen muss dort als Eigenschaft der Text "[Ereignisprozedur]"
stehen, - wählt man normal aus dem Kombi aus. Kann man aber auch
leer lassen, dann wird auch kein Code beim Eintreten des Ereignisses
ausgeführt. Ich finde allerdings das Auskommentieren im VBE bequemer.
gruss ekkehard

 

\@drambeldier
Sag mal.. Gibts auch mal eine Antwort auf meine Fragen. Ich habe explizit dich und später die Frage an alle gestellt.

Wir reden hier nicht mehr von irgendetwas was ich zu tun gedenke, sondern davon, dass mir hier reingehauen wird, dass der Ablauf festgenagelt ist. Und ich (egal wie oft ich die Seite auch lese, den Grund da nicht rauslesen kann), aber bei meinem Test eine andere Reihenfolge habe.

Ich habe mir sogar die Mühe gemacht mit der Exceltabelle und der DB und anstatt mir zu sagen wie das Zustande kommt das Ergebnis, bekomm ich wieder mal eine Antwort auf eine Frage dich ich nicht gestellt habe.

Wenn mir die Seite jetzt zum 20 igsten mal durchlese (Ja so oft hab ich die nun schon druch, das ist kein Scherz), lese ich dort nur:

Wir sind dafür, das wir dagegen sind. Aber wenn wir dagegen sind, kanns auch mal passieren das wir dafür sind. Wenn wir dafür und dagegen sind, tritt Fall b ein. Wenn fall B eintritt, kann es sein das wir dagegen sind usw...

Genau das lese ich da raus. In Hundert Jahren kann sich das keine Sau merken.

Und nochmal falls dur dir die Exceltabelle und die DB immernoch noch nicht angschaut haben solltest:

Dort drin ist genau bei Spalte B zu sehen, das der Ablauf eben nicht wie auf der Seite von MS unter dem Punkt "Ereignisse für Formulare und Unterformulare "angegeben ist: open -> load -> current. Sondern: Load-> Current -> Open. Und für diejenigen die mir nicht glauben hab ich eben die DB mit angehängt.

Und wenn mir dies einer, ohne mir dabei wieder zig Fachbegriffe um die Ohren zu hauen erklären könnte, wäre ich sehr dankbar.

Sorry, bin grad bissl unter Strom..


@ Beaker s.a gerade erst gelesen. Ach so meinste das. Ich dachte gebe ne Möglichkeit, das zu automatisieren. Dachte man könnte die "Ereignisprozdur" dort temporär außer kraft setzten oder löschen. Naja wär ja auch zu schön ^^

 

Ich kann Deinen Ausführungen nicht folgen.

 

\@ Nouba

OK ich erklärs nun ganz genau:

Ich habe eine TestDB und eine Exceltabelle angefügt.
Man öffne die TestDB
Man öffne die Excelltabelle
Man öffne das Formular "frm_ProdukteGruppenUndProdukte" mit einem Doppleklick
Man vergleiche nun Spalte A in der Exceltabelle mit den MsgBoxen. Dies ist die Reihenfolge die laut MS so gehört.
Man schließe wenn man fertig ist das Formular
*******************************************************
Man öffne den VBA Editor, gehe ins Form_frm_ProdukteGruppenUndProdukte suche dort den Eintrag Private Sub Form_Open. Dort das ' Zeichen vor dem Befehl DoCmd.GoToRecord , , acNewRec entfernen.
Man schließe den VBA Editor.
*******************************************************
Man öffne das Formular "frm_ProdukteGruppenUndProdukte" mit einem Doppleklick
Man vergleiche nun Spalte B in der Exceltabelle mit den MsgBoxen. Dies ist sicher nicht die Reihenfolge die laut MS so gehört.
Man schließe wenn man fertig ist das Formular
*******************************************************
Man öffne den VBA Editor, gehe ins Form_frm_ProdukteGruppenUndProdukte suche dort den Eintrag Private Sub Form_Open und setzt dort wieder ein ' vor den Befehl DoCmd.GoToRecord , , acNewRec
Man suche dann dort den Eintrag Private Sub Form_Load. Dort das ' Zeichen vor dem Befehl DoCmd.GoToRecord , , acNewRec entfernen.
Man schließe den VBA Editor.
*******************************************************
Man öffne das Formular "frm_ProdukteGruppenUndProdukte" mit einem Doppleklick
Man vergleiche nun Spalte C in der Exceltabelle mit den MsgBoxen.
Man schließe wenn man fertig ist das Formular
*******************************************************
Man öffne den VBA Editor, gehe ins Form_frm_ProdukteGruppenUndProdukte suche dort den Eintrag Private Sub Form_Load und setzt dort wieder ein ' vor den Befehl DoCmd.GoToRecord , , acNewRec
Man suche dann dort den Eintrag Private Sub Form_Current. Dort das ' Zeichen vor dem Befehl DoCmd.GoToRecord , , acNewRec entfernen.
Man schließe den VBA Editor.
*******************************************************
Man öffne das Formular "frm_ProdukteGruppenUndProdukte" mit einem Doppleklick
Man vergleiche nun Spalte D in der Exceltabelle mit den MsgBoxen.
Man schließe wenn man fertig ist das Formular

So Falls jetzt noch was unklar sein sollte, dann weiß ich nicht mehr weiter..

 

Moin,

hier mal den ganzen Ramsch auf einen Blick: Formulat -> Entwurf -> Formular
Code:

Such jetzt bitte nach Open -> Current -> Load.

Mein Vorgehen: Ersetze "msgbox" durch "Debug.print" allüberall.

 

Ich versuch mich jetzt bissl zurückzuhalten.

Habe ich irgndwo die letzten Postings, bei denen es darum ging, dass ich in dieser Datenbank einen anderen Ablauf habe als es MS sagt irgendwo etwas von Entwurfsansicht oder Wechseln gesagt ? NEIN

Also Entweder du schaust dir jetzt das Beispiel und die Exceltabelle an, oder ich ignoriere es einfach.

Schau dir die Anleitung an und die Tabelle und die DB und du wirst feststellen, dass dort der Ablauf eben NICHT so ist, verflucht noch eins....

Es geht inzwischen nicht mehr um irgendeine Entwurfsansicht, sondern ganz normal der Ablauf wenn man ein Formular öffnet. Wenn ich dann sage entweder ganz normal ohne Code laden, dann passt die Reihenfolge. Lass ich aber die DB bei einen der drei Events Form_Open oder bei Form_Load oder bei Form_Current mit einem neuen DS laden dann ist jedesmal der Ablauf ein anderer (Wobei in der Tabelle ersichtlich ist, dass bei Spalte C und D nur die Ereignisse des Steuerlements variieren. Dann schau dir Spalte B und dann sag mir dass da die Reihenfolge open, load, current ist...


Komm mir hier langsam bissl vergageiert vor. Ich frage: Was ist heute fürn ein Tag ?" Und bekomme als Antwort: "Vergiss es, irgendwann ist mal wieder Sonntag"


***********************************************************
Habs jetzt mal ganz einfach gemacht. Noch einfach geht nicht mehr:

Es sind jetzt 4 DB. Man Öffne DB 1 und das Formular und vergleiche in der Tabelle mit Spalte A. Man öffne DB 2 und das Formular und vergleiche mit Spalte B in der Tabelle. Man öffne DB 3 und das Formular und vergleiche mit Spalte C in der Tabelle. Man öffne DB 4 und das Formular und vergleiche mit Spalte D in der Tabelle. Das Vergleichen ist nur dazu da, damit ihr euch die Arbeit nicht machen müsst, dass alles auf ein Blatt Papier zu schreiben um zu vergleichen. (Außerdem hätts ja sein können das ich in der Tabelle was durcheinander gebracht hätte. Ich habs nun aber zig mal getestet und das Ergebnis ist immer das gleiche)

 

Hallo,
Ich hab' jetzt keine Lust mir das noch mal anzusehen oder selber zu testen,
aber IMO wird Form_Current durch DoCmd.GoToRecord , , acNewRec
erneut ausgelöst, was nach dem 1. Form_Current zur Veränderung der
Reihenfolge führen kann.
Die korrekteste Reihenfolge bekommst du nur mit Einzelschrittausführung
heraus.
gruss ekkehard

 

Hallo,
Form_Current wird durch jeden Datenswechsel erneut ausgelöst, auch wenn das über VBA mit GoToRecord gemacht wird, wie von Ekkehard auch gesagt.
Die ganzen Ereignis müssen immer im Kontext gesehen werden und auch so ablaufen.
Wenn z.B. im Entladen noch ein Requery auf ein Unterformular abgesetzt wird, kommt Current des Ufo noch vor dem Entladen des Ufos obwohl das Entladen ja gar nix mit Current zu tun hat.
Den Ereignisablauf an bestimmten Konstellationen festzumachen macht keinen Sinn, weil dieser Ablauf durch programmieren der Oberfläche ganz anders werden kann. Es kann auch durchaus sein, dass Current 2x kommt weil eben ein Requery noch dazwischen funkt.

Ich glaube, die 5 Testdateien hast Du für die Katz gemacht, das interessiert wahrscheinlich nicht viele User wirklich.
Du wirst es an den Downloadzahlen sehen.

 

Moin,

jetzt gibt es 2 Möglichkeiten: Entweder hast Du einen Fehler in der Access-Doku entdeckt oder die Doku nicht genau genug gelesen. Ist aber auch wurscht, weil die Beantwortung dieser Frage Dich in Deinem Projekt keinen Schritt weitergebracht hat. Ungefähr ist nämlich wie fast meistens im Leben genau genug.

Ich kriege gerade den Kerl nicht aus dem Kopf, auf dessen Grabstein stand: "Er kam von rechts".

Ean anderer Aspekt: Glaubst Du im Ernst, dass irgendjemand 5 Dateien runterlädt, um sich Messageboxen anzuschauen und deren Auftreten fein säuberlich zu notieren? Ich habe Dir gezeigt, wie solche Tests zu gestalten sind, damit die Ergebnisse auf einem Blatt Papier erscheinen; dann besteht wenigstens die Hoffnung, dass sie gelesen werden.

 

Es geht hier schon lange nicht mehr um ein Projekt, sondern ich möchte wissen, ob es bei jedem so ist oder nur in meiner TestDB bzw. meinem Access.

Da sieht man´s mal wieder: Du sagst anderen Leuten das man was lesen sollte und auch verstehen und machst ebenfalls NICHT.

Wenn du gelesen hättest und verstanden hättest, dann wäre dir aufgefallen, dass niemand etwas hätte aufschreiben müssen. Dafür habe ich ja extra die Exceltabelle gemacht in der man nur die angezeigten Nachrichten mit denen in der Tabelle vergleichen hätte müssen.

Und ich weiß nicht was jetzt so groß der Unterschied ist, sich die MsgBoxen anzuschauen und ok zu drücken, oder im VBA Editor überall Haltemarken zu setzten, um dann andauernd F8 zu drücken. (Also zumindest für einen Ablauf, welches Event gerade angesprungen wurde. You see what you get. Für andere Sachen ist der VBA Editor sicherlich besser.)

Und auch an deiner Antwort aus Beitrag #67

Kann man genau sehen, das du eben NICHT gelesen hast (und nicht nur du)

Solltest du (und adere) gelesen haben, dann hast du´s (und andere) nicht verstanden. Deine Antwort zeigt mir, dass du die DB geöffnet hast und das Formular geöffnet hast. Du hast aber nicht bemerkt, dass dieser Test 4 Mal durchzuführen gewesen wäre. Man hätte nämlich Code "scharf machen" müssen bzw. dann wieder auskommentieren müssen. In der TestDB ist sämtlicher Code im Urzustand auskommentiert. Weshalb auch die Reihenfolge so ist wie sie gehört.

So ganz kann ich der Aussage nicht zustimmen bzw. wenn ich mir das in Einzel-Schritten im Editor anschaue, dann sieht das für mich folgendermaßen aus:

Er führt Sub Form_Current nicht 2 Mal aus sondern:

Er führt Current aus geht innerhalb der Sub zu DoCmdGotoRecord , , acNew und jetzt springt er aus der Sub raus zur Sub ProduktGruppen_Enter geht diese durch, geht zur Sub ProduktGruppen_GotFocus geht diese durch und jetzt springt er wieder zurück in die Sub Form_Current.

Habe am Ende mal ein Bild angefügt mit den Einzelschritten aus dem Debugger.

Ist auch bei den anderen Beispielen so. Also wenn der Code DoCmdGotoRecord , , acNew in der Sub Form_Open oder in der Sub Form_Load steht. Er springt immer aus der Sub führt aus was er meint ausführen zu müssen und springt wieder zurück.

Nur wieso, ist das was er nach diesem Code anspringt, jedes Mal eine andere Sub (Event), je nach dem in welcher Sub sich der Code befindet.

Bzw. hat ja gpswanderer eine mögliche Erklärung gefunden.

@ gpswanderer

Also wenn ich deine Aussage lese, weiß ich zwar was du meinst. Aber ist das was ich da nun habe bei jedem so, oder ist da was mit meinem Access ? Und falls es bei jedem so ist, liegt es nur an diesem Befehl, oder gibt’s noch andere Befehle die so ein Durcheinander in der Reihenfolge hervorrufen ?

Obs an meinem Access liegt oder immer so ist, ließe sich ja nur herausfinden, wenn jemand meine TestDB nachbaut ohne zu importieren oder Code zu kopieren. Glaube nicht das sich da jemand die Mühe machen will ^^ (Wobei man ja nur die HFO Events mit dem Code DoCmdGotoRecord , , acNew jeweils entweder in Open oder Load oder Current braucht. Die UFO Events und die MsgBoxen braucht man ja nicht.

Und falls es bei jedem so ist, dann heißt das dann aber auch das die ganzen Beschreibungen mit den Reihenfolgen für´n Popo sind. Ich meine bei fast jeder Anleitung, die jetzt nicht aus einem Forum stammt, steht überall: "Es ist wichtig zu wissen welches Ereignis wann eintritt. Bla bla"


Shit Bild vergessen *biggrin.gif*

 

weil Du es bereits aufgeschrieben hast? Das ist Kappes. Der Output ist maschinell zu erzeugen, das ist die Mindestanforderung beim Testen.

 

Och ja das ist jetzt mal wieder relevant für das was ich geschrieben habe..*rolleyes.gif*

Der output wurde maschinell erzeugt. Oder meinst ich hab mir das aus den Fingern gesaugt? Ne grundvoraussetzung fürs Testen ist auch den Testablauf zu kennen, vor allem wenn mir jemand schon eine DAU Anleitung mitlierfert.
Wenn man sich das Zeug selbst erarbeiten muss, dann kann ich das verstehen, das mal was nicht so ist

 

Hallo,

GotoRecord im Current unterzubringen ist absolut sinnlos. Der Sprung zu acNewRecord lösst Current aus, Current dann wiederum den Sprung mit AcNewRecord. Das gibt eine klassische Endloschleife und Access hängt.
Und das ist bei jedem so,
Daher ist es ziemlich sinnlos, die Ereignisreihenfolge an einem festen Ablauf festzumachen. Wenn Unterformulare ins Spiel kommen, muss man das ohnehin immer etwas probieren, denn wenn ich recht weiß, werden Ufos vor dem Hafo geladen, was dann auch wieder eine völlige andere Ereignisabfolge zur Folge hat.

Von daher, ist Dein ganzer Aufwand ziemlich für die Katz. Weil auch (wie bereits gesagt) die Reihenfolge von der Programmierung beeinflusst wird.
Du kannst das Open Ereignis auch per Befehlsbutton auslösen. Z.B. so:
Code:

Und dann kommt zusätzlich wahrscheinlich auch "Beim Laden" (Load) und "Beim Anzeigen" (Current).
Das Beispiel macht jetzt so keinen Sinn, es dient nur dazu Dir aufzuzeigen, dass die Reihenfolgen nicht zwangläufig immer gleich sind.

Ich hatte auch als Anfänger niemals das Bedürfnis das klären zu wollen, weil es einfach zu viele Zusammenhänge bzw. Abläufe im Hintergrund gibt.