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

Bei gar keinem Event. -> Außer du willst es über einen Commandbutton anstoßen.

Ansonsten bleibt das Formular ja für eine einzige Aktion blockiert.
Das macht keinen Sinn.

 

Also bevor wir weitermachen könntest du mir eventuell Antworten auf meinem Beitrag eine Seite weiter vorne geben ?

Der beginnt mit

Na dann erklär mir halt die Basics.

Weil ich immernoch keine Antwort habe wie Ihr das löst.

Weil solange ich darauf keine Antwort habe, werde ich auch nicht davon wegkommen, dass ich das Formular so anpasse, das beim Wechsel in und aus der Entwurfsansicht keinerlei Code ausgeführt wird. Außer der Code der anhand des Zustandes "Entwurfsansicht" den letzten DS wieder herholt, als ich zuletzt, bevor ich in die Entwurfsansicht bin, am bearbeiten war.

 

Hallo,

Im Ereignis "Beim Öffnen" der Formulare:
Code:

Mache ich mir keine Gedanken, auch jetzt nicht, brauche ich nicht und habe ich noch nie gebraucht.

Du kannst es Drehen und Wenden wie Du willst, Du beschäftigst Dich mit Sachen die man nicht braucht. Verwende Deine Programmierenergie zur Gestaltung einer ansprechenden Oberfläche.
Und damit verabschied ich mich auch aus dem Thema, ist mir viel zu abstrakt.

 

Ja wie jetzt. Du hast als du damit anfingst, keine Experimente gemacht? Du hast gleich alles gewusst, wo was hinkommt ? Du hast nie ein Formular mit VBA bearbeitet. Hast dann das Formular nie geöffnet und dann beim Eingeben von Daten festgestellt, das was nicht stimmt und bist in die Entwurfsansicht gewechselt ?

Und falls doch, muss dir doch dann aufgefallen sein, das wenn dein Formular nicht 100 % ig fertig ist (weil man zb vergessen hat, in VBA zu programmieren, das der User das Feld nicht verlassen darf solange das Feld leer ist) und man dann in die Entwurfsansicht wechselt, dass dies dann zu Fehlern führt.

Also ich meine:

Ich sitzte hier hab Access das Formular offen und bin nun am Testen ob das Formular bei der Eingabe von Daten das macht was ich wollte, bin mitten im Eingeben und stelle fest, das ich zb das Feld doch verlassen kann obwohl ich programmiert habe, das das nicht passieren soll. Oder das ich dann auf die Idee komme und sage:
"hm das ist nicht so wie ich mir das gedacht habe. Hm leg ich halt schnell nen Button an. Also ab in die Entwurfsansicht. Und schon gibts fehler oder MsgBoxen die für den User gedacht sind tauchen auf usw."

Oder mal konkretes Beispiel:

Ihr habt programmiert, das der User ein Feld nicht verlassen darf solange dies nicht ausgefüllt ist. Der User bekommt eine Nachricht. Ihr öffnet das Formular, seid dabei Daten einzugeben und geht dann in die Entwurfsansicht (oder Ihr gebt gar keine Daten ein, dann ist das Feld auf alle Fälle leer). Dh es tauchen dann auch die MsgBoxen auf das Feld nicht leer sein darf und je nach dem wie groß das Formular ist können das doch ein paar werden.

Nervt euch das nicht, das man bevor man in die Entwurfsansicht kommt erstmal 5 MsgBoxen wegklicken muss. und wenn man wieder rausgeht nochmal (Mal ganz abgesehen von unfertigen Code, der dann ausgeführt wird)

Und wie gesagt eventuell passiert das ja jemand nicht, der sofort weiß, was er da macht. Aber jeder hat doch irgendwann mal angefangen ? Ich mein wie seid ihr damit umgegangen ?

Heißt das dann, dass ich die Entwurfsansicht erst dann verwenden darf wenn ich mir 100 % ig sicher bin das auch alles in meinem Code passt oder wie ?


Also wenn ich wie vorgeschlagen:

Im Ereignis "Beim Öffnen" der Formulare:

DoCmd.GoToRecord, , acNewRecord

unterbringe kommt:


"Fehler beim Kompilieren"
Variable nicht definiert



DoCmd.GoToRecord, , acNewRec

Geht. .............

 

Hallo,

Nein, weil wir solche wie deine nicht haben. Und du hast die ja auch nicht
mehr, wenn da richtiger Code drinsteht. Und den bekommst du beim Ablauf
nur zu sehen, wenn da ein Laufzeitfehler auftritt. In dem Fall klickst du auf
"Debuggen", landest im VBE mit markierter fehlerverursachenden Zeile und
klickst auf "Zurücksetzen" (kleines, blaues Quadrat etwa in der Mitte der
Symbolleiste) und jeder weitere Code wird nicht mehr ausgeführt.
Neben dem Vorschlag mit Debug.Print statt MsgBox zu werkeln wenn du
der OH nicht traust, kannst du dir den Programmablauf auch mit dem Setzen
von Haltepunkten und Einzelschrittausführung anschauen. Da siehst du dann
auch inwieweit dein Code in die Abläufe eingreift.
gruss ekkehard

 

Hallo Kant_Holz

du machst es dir ja schwer.
MS verstehen zu wollen, anstatt damit zu leben.*biggrin.gif*

Als User der Anwendung würde es mich nerven, wenn überall immer Pop-up Fenster aufgehen. Vielleicht auch noch nichtmal auf dem Bildschirm, auf dem ich gerade arbeite, sondern auf einem anderen.

Schonmal daran gedacht, Label/Bezeichnungsfelder mit der "Warnung/Anweisung" direkt im Feld oder daneben sichtbar werden zu lassen?

MsgBoxen habe ich zu Anfang auch sehr viele verwendet, aber die nerven irgendwann nicht nur beim coden, wie bei die, sondern auch in der täglichen Anwendung.

Als ich angefangen habe, habe ich auch zu ziehmlich alles getestet und ausprobiert, aber ich hatte auch immer alles Offen und bin selten immer wieder hin und her gesprungen.

Ja, hatte mal etwas ähnliches mit Plausibiltätsprüfung. Als ich das ausreichend getestet hatte habe ich dort einfach für die weitere Entwicklung einen Dummywert verwendet.

Generell schreibe ich Code in etxra Modulen/Klassen und rufe diese in den Steuerelementen nur auf. So lassen sich die Steuerelemente viel einfach er funktionslos schalten, einfach nur eine Zeile auskommentieren.

Je nach Funktion, lässt sich der Code so auch wiederverwenden und ist leichter zu updaten.

Ich will mich eigentlich nicht zu weit aus dem Fenster lehnen, aber vielleicht ist deine Herangehensweise an Planung, Umsetzung und testen eine ganz andere.

 

ESC hilft ganz gut gegen penetrante Messageboxen.

Du hast doch die Messageboxen programmiert. Du kannst sie doch auch einfach wieder entfernen bzw. durch eine weniger invasive Art der Ausgabe ersetzen.
Für Debug-Ausgaben gibt's zb. das Direktfenster der VBA Umgebung.
Benutzerinformationen kann man auch in ein Label im Formular schreiben.

Was macht denn der Benutzer, wenn er den Vorgang abbrechen will? Muss der dann auch die zahllosen MsgBoxen wegklicken?

 

Hm jetzt kommen wir der Sache schon näher.

Daran könnte es liegen

Weil ich z.B.

dies nicht verstehe. Ich mein ich sehe ja anhand deiner Aussagen, dass es durchaus auch anderen so ging.

Das war schon immer mein Problem. Ich war noch nie der dem man nen Brocken hinwirft und dann meint friss oder stirb. Ich wollt schon immer wissen, warum die Dinge so sind. Und geht nicht gibts nicht. Außer zu wenig Zeit um Sachen zu lösen.


Aber ich bin auf eine Idee gestoßen, warum diese MsgBoxen (hauptsächlich die auf Prüfung ob ein Feld leer ist) überhaupt auftauchen, wenn ich in die Entwurfsansicht wechsle. Muss das mal testen. Ich glaube zu ahnen was der Fehler ist.

Weil wie gesagt Beaker s.a. hat mich langsam stutzig gemacht. Wenn er diese Probleme nicht hat, muss es ja irgendwo am Code liegen.

Auch wenn immernoch das Problem bleibt, das ich beim Testen in die Entwurfsansicht muss. Und wenn ich da dann Code drin hab, der nicht so richtig passt wie es sich gehört (also kein Syntaxfehler ) sondern eher das ich da z.B. Code im falschen Event habe und dieser sich mit Anderen sachen in die Quere kommt, wird mehr oder weniger unfertiger Code ausgeführt der wiederum adere Sachen nach sich zieht. Was mich manchmal zur Weißglut treibt.

Ich glaub ich versteh Access einfach nicht. In VB wenn ich da was mache sieht das in etwa so aus:

Ich brauch da dies und das. OK Google. Ah da schnipp schnapp eingefügt angepasst und geht.

Hier in Access. OK Google. Ah da schnipp schnapp eingefügt angepasst und geht. Heee warum geht jetzt das, aber dafür geht dies was bis eben noch ging nun nicht mehr ?????????? Und dann fängt das rumgedoktere an, weil man ja wissen möchte was der Fehler ist. Hat man einen Fehler ausgemerzt, geht wieder was anderes nicht mehr.

Ich mach mich mal dran, an meinem allerersten "ausgedachten" daheim zum erstenmal Access aufgemachten Beispiel. (das aus dem Eingangspost mit dem Streitthema Adressen und Namen) *grins ich denke das ich da einen Fehler habe, und diesen dann immer brav in meine richtige DB mitkopiert habe..

 

Moin,

habe ich schon mal erwähnt, dass hier ereignisorientiert gearbeitet wird?

Alle Codes für Ereignisse liegen nebeneinander, ohne dass was passiert. Sobald ein Ereignis eintritt, geht die Steuerung an die zum Ereignis gehörende Prozedur.

Das ist, nebenbei gesagt, der Grund dafür, dass beim Wechsel in die Entwurfsansicht all das ausgeführt wird, was zum Schließen des Formulars gehört, und beim Wechsel in die Formularansicht das, was zum Öffnen gehört. Während der Arbeit im Entwurfsmodus werden keine Ereignisse ausgelöst.

 

Nur gegen Schmerzensgeld.
Dafür gibts Bücher. Da geht das systematisch- zuerst die Grundlagen.
So kommst du am Schnellsten ans Ziel.

 

Hm und warum lese ich dann überall, dass man wissen muss welches Ereingis wann eintritt? Also wenn du dir meinen Beitrag anschaust wo ich das Experiment gemacht habe, um zu zeigen sobald auch nur 1 Zeile Code irgendwo steht, das der urprüngliche Ablauf der Ereignisse eben nicht mehr der selbe ist, woher soll ich dann wissen welche Ereigniskette nun eintritt wenn ich in einem Eregnis Code unterbringe ?

Die Aussagen die überall zu finden ist das man wissen muss welches Eregnis wann eintritt beißt sich dann, weil man dann eben nicht mehr weiß wie die Ereigniskette ist.

Ja das ist wiederum klar, da ja eben das Formular jedesmal geschlossen und geöffnet wird beim Wechsel. Ich frage mich halt eben warum muss das jedesmal geschlossen und geöffnet werden ? Was hat sich MS dabei gedacht?
Es wäre ja wohl für MS sicher kein Problem gewesen, zu sagen Sobald Entwurfsansicht gedrückt wird kein Code ausführen.

Wie gesagt bei VB wird auch kein Code ausgeführt solange bis ich sage "Jetzt Code ausführen"

Will sagen: Bei Access ist die Entwicklungsumgebung einfach sch...

Und wie man sieht gibt es druchaus Leute, die ähnliche Probleme haben. Und wenn ich deren Aussagen mir anschaue, veruschen die sich mit manchen Sachen zu behelfen (z.B. Auskommentieren usw.). Und was ich mache ist nix anderes nur mit größerem Umfang und Aufwand.

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


Ich dachte ich hätte das Problem lokalisiert, aber es liegt an einer Eigenart die mir halt auch nicht gefällt, womit aber die meisten wohl anscheinend leben.

Ich sehe das aus der Sicht des Users. Dort sollte, wenn ich Fehler mache im Formular, der Hinweis sofort kommen und nicht erst, wenn ich versuche den DS zu speichern.

Konkretes Beispiel:

HFO für das Bsp nicht relevant. Im UFO existieren 2 Steuerelmente (Text) die als Herkunft Tabelle Personen hat nämlich Steuerlement 1 = Vorname und Steuerlement 2 = Nachname. Keinerlei Code vorhanden.

Beispiele die ich sehe machen das wie folgt. Der User gibt nix in Vorname ein (aus welchen Gründen auch immer). Gibt dann bei Nachname was ein und will den DS speichern (Wobei ich ja der meinung bin, das dies automatisch geschehen sollte und nicht über einen Button, aber da ist andere Baustelle. Und nein ich meine nicht automatisch speichern, sondern Reihenfolge wie was auszufüllen ist festlegen, beim verlassen des letzten Feldes alles nochmal prüfen und dann eine MsgBox oder sonstwas, wo abgefragt wird ob er speichern oder abrechen möchte)
Dann wird er darauf hingewiesen, das Feld Vorname nicht leer sein darf.
Gut bei 2 Feldern mag das nicht so sehr ins Gewicht fallen, aber bei mehreren Feldern erst beim Speichern den User darauf hinzuweisen, ist für mich unlogisch. "Strafen" müssen stante pede erfolgen und nicht erst später.

Also hab ich mir überlegt das der User das Feld eben solange nicht verlassen kann, bis er bei Vorname was einträgt.

Ok dann suchte ich nach dem richtigen Ereignis:

"Bevore_Update" im Feld Vorname: Geht nicht da dies nur feuert, wenn schon mal irgendeine Taste (Eingabe) in dem Feld gedrückt (gemacht) wurde.

"Enter" von Feld Nachname: Prüfen ob Feld Vorname leer ist, dann MsgBox, Fokus wieder auf Feld Vorname. Ist die umständlichere Art

"Exit" von Feld Vorname: Scheint mir das richtige, da ich hier sogar ein Cancel Event habe.

Code:

und hier die Funktion Quelle: www.dbwiki.net oder www.dbwiki.de

Code:

Ok. Jetzt versucht mal wenn das Formular geöffnet ist in die Entwurfsansicht zu gelangen. 5 x kommt nun die MsgBox "Feld Vorname darf nicht leer sein"


Und das ist nur eins von vielen Sachen die mich nerven wenn ich in die Entwurfsansicht wechsle und wieder zurück.

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



Aber zu sagen: "Das ist Unsinn was ich vorhabe" kann ich so nicht stehen lassen.

Das seh ich jeden Tag da draußen. "Das haben wir schon immer so gemacht, also wirds auch weiterhin so gemacht" Nur weil von 100 Leuten 98 der Meinung sind, muss ich nicht auch dieser Meinung sein. Und das hat nichts damit zu tun, dass ich nichts annehme. Sondern ich versuche mir selbst ein Bild zu machen und entweder ich komme dann auch zum Entschluß wie die 98 anderen, oder eben nicht.

Wisst Ihr meine Meinung ist: Fußball ist Unsinn. (Was für den einen Schwachfug ist des anderen Lebensinhalt)

Aber ich gehe nicht her und versuche den Leuten auszureden Fußball zu schauen. Manche versuchen mir das auszureden, weil es ihrer Meinung nach Schwachsinn ist, was ich möchte. Zum Glück gibts aber so Leute wie mich, die eben nicht den Lemmingen hinterherrennen, ansonsten würden wir vielleicht noch in der Höhle sitzen, weil wenn alle Herdentiere wären, würden wir dann immernoch sagen: Naja wir sitzen schon immer hier in Höhlen, machen wirs weiter so.

Und teilweise ist ja das Problem schon gelöst, von Markus. Ich wollte halt nur, dass mir wer sagt ob und wie man sowas Global bzw Accessweit zur Vefügung stellen kann.

Und wenn es mal fertig ist, kann ich dann das ganze veröffentlichen. Und wenn von 1000 nur 2 dabei sind, denen es hilft, dann ist mir wurscht ob 998 Leute das nicht brauchen. Es hat 2 geholfen Punkt

Und das schöne ist: An den Reaktionen die auf den Beitrag folgen werden, kann ich sehen, wer hier dann mit allen Mitteln versucht sich zu rechtfertigen, warum er den Lemmingen hinterherrent, und weiterhin der Meinung ist, dass es anders gehört. Die anderen, werden dann versuchen mir bei meinem Problem zu helfen.

 

Schnell schreiben können reicht nicht, manchmal muss man auch ein wenig lesen. So zB den Link, in dem die Reihenfolge beschrieben wird, in der die Ereignisse ausgelöst werden. Diese Reihenfolge ist ein für allemal festgelegt, da pssiert nicht heute dies und morgen jenes.

 

Hi KAntholz,

ich muss deinen letzten Post mal kurz aufgreifen. Wenn Du eine Überprüfung machen willst ob Felder leer sind, die PFlicht sind, dannist Dein Ansatz komplett ungeschickt.
Besser wäre wenn du vor dem schließen des Formulars die Felder prüfst. Oder vor dem Speichern. Aber nicht so wie Du es tust.

Meinen Respekt möchte ich noch den Kollegen zollen, die Dir nach wie vor versuchen zu helfen und Deine Texte lesen. *Smilie

Bind dann wieder weg.

Viele Grüße
trekking

 

Hallo,

Die ganze Zeit, die du in deine ellenlangen Postings investierst, solltest du
lieber mit dem Lesen der OH verbringen.
Dein Problem ist mir nicht neu, - mir ging es am Anfang genauso mit den
ganzen Events. Mit viel rumprobieren (MsgBoxen, Debug.Print, Logdatei,
Einzelschrittausführung!) und Hilfe der OH (hab' in einem Jahr drei
Tastaturen "verbraucht", weil alle paar Monate die F1-Taste geschmolzen
war *wink.gif* ) und aus Newsgroups bin ich dem so langsam auf die Spur
gekommen. Und an das dementsprechende (ereignisorientierte) Verhalten
von Access gewöhnt man sich.
Übrigens noch eine Lösung um Ereignisse zu unterdrücken, ohne den Code
auskommentieren zu müssen, ist das temporäre Löschen des Eintrags
"Ereignisprozedur" in der zugehörigen Eigenschaft (z.B. "Beim Laden").

gruss ekkehard


P.S. Irgendwann war das aufkommende Verständnis dann "der Beginn
einer wunderbaren Freundschaft".

 

Du hast natürlich recht, das man den User "unterstützen" sollte, erwähnt habe ich es ja bereits, aber MsgBoxes unterstützen nicht, sondern unterbrechen den Arbeitsfluss, und nerven irgendwann auch nur noch.

Besser wäre es, die Anweisung über ein freies Label "sichtbar" zu machen.

Die Erziehung der User kann auch recht schnell dazu führen, dass man nur noch Müll in den Feldern hat. Dann wird mal gerne und schnell ein x oder eine 0 eingetragen, damit man schnell zu den anderen Felder kommt.

Also ich frage mich gerade warum du die Felder in den Unterformular nicht mit den Tabellen verknüpfst und die Einstellung "Eingabe erforderlich" für die Felder definierst?
Auch wenn ich verstehe auf was du hinaus willst, so habe ich gerade eher das Gefühl, du willst das Rad neu erfinden.

Und manchmal kann man deiner Argumentation eben auch gar nicht folgen.

Ich verstehe einfach nicht was du hier mit "automatisch" meinst, wenn du doch nicht "automatisch" gemeint hast.