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

Ist keine gute Idee.
Wenn ein Anwender in der Praxis das Formular einfach schließt, dann passiert genau das gleiche was jetzt passiert wenn du auf den Entwurf wechselst.

Da darf höchstens die Frage kommen ob wirklich geschlossen werden soll und dann muss Schluss sein. Du musst also die Programmierung dahingehend ändern.

Zum möglichen Code selbst:
Weist du wie man Verweise auf fremde Bibliothen erstellt?
- Commandbars sind ja keine Bestandteil von Access.
Weist du wie man mit Events und der WithEvents Anweisung umgeht und was die Voraussetzungen sind?
Verstehst du den Umgang mit Objekten in VBA?

LG Markus

 

Solche Beispiele aus den Tiefen eigener Verwirrung sind bestens geeignet, lange und fruchtlose Diskussionen anzuzetteln - es soll Leute geben, die halten Geschriebenes für Wahrheit und reagieren darauf ...

Es gibt so etwas wie bedingte Kompilierung. Ob die aber bei diesem speziellen Arbeitsmodus verwendbar ist, kann ich nicht sagen.

Wenn man seine Prozeduren übersichtlich und vernünftig schreibt, wird es aber allermeistens auch kein Problem sein, wenn dieser Code ausgeführt wird. In der späteren Anwendungspraxis wünscht man das sogar. Man sollte da nur auf Schleifen über viele Datensätze mit eingelagerten Userinformationen per MsgBox, auf Endlosschleifen und derartiges verzichten. Eigener Programmierstil zieht dann auch die Notwendigkeit bestimmter Nachfolgemaßnahmen nach sich - oder eben nicht.

Da dürftest Du Dich in den Quellcode von Access einarbeiten, was extrem ambitioniert wäre, zumal da Hilfe aus verschiedenen Gründen nicht zu erwarten ist. Genau richtig als Anfängeraufgabe.

 

Na endlich geht’s mal in die richtige Richtung *grins

Hab bisher folgende eingebunden:

- Microsoft Office 15.0 Object Library (brauchte ich für die Experimente mit der Ribbon X geschichte)
- Microsoft ActiveX Data Objects 6.1 Library
- Microsoft ADO ext. 6.0 for DLL and Security (Hab ich drin wegen einer Funktion)

+ die 3 Standard die eh immer eingebunden sind.

Oh Gott das riecht fast nach eigener Klasse erstellen... Ich hab mir schon gedacht das das wieder mal nicht einfach wird.

Ich hab auch den Überblick verloren, weil irgendwie hatte ich ja Sachen gefunden, die meisten bezogen sich aber immer auf Excel und da gibt’s halt Sachen die in VBA für Access nicht immer funktionieren, soweit ich das verstanden habe. Und dann ist da immernoch die Geschichte, dass alles was ich finden konnte, sich mit eigenen Kontextmenüs beschäftigte. Und da reicht mein jetziger Wissenstand einfach nicht aus, um mir aus dem gefunden Sachen den Code so umzuschreiben, bzw. den für mich relevanten Code rauszusuchen.

Das soll ja auch später NICHT in die Produktiv DB. Das ist für mich solange ich noch "Experimentiere". Da ich ja in so gut wie jedem Event, welches nach dem Öffnen (Open, OnLoad, Current usw.) und beim Schließen (Unload usw.) ausgelöst wird (im UFO und HFO) eine MsgBox habe. Diese zeigen mir zum Beispiel: "HFO geöffnet. Variable XY lautet:" usw. Dann sind da noch ein paar MsgBoxen damit ich sehe wohin der Fokus wandert. Außerdem bekommen die Leute später von mir gar keine Möglichkeit die Entwurfsansicht zu nutzen^^

Wenn man jetzt am Testen ist und mittendrin einem noch was einfällt (passiert beim tüfteln öfters *grins ) und man dann auf die Entwurfsansicht schaltet, dann dauert es halt mitunter ewig alle MsgBoxen zu bestätigen. Dann schiebt man irgendwas rum, geht in den Code und geht wieder in die Formularansicht. Dann geht das Spiel von vorne los. Jetzt ist es auch so, dass ich da Sachen per VBA habe die einen Bestimmten Ablauf vom User erzwingen sollen. Solange aber der komplette Ablauf noch nicht fertig ist (wie gesagt ich experimentiere ja noch) kann es passieren, dass man sich in einem Steuerelement befindet, das im späteren Ablauf zu diesem Zeitpunkt gar nicht möglich ist anzusteuern. Geht man jetzt, weil man gerade mal wieder nicht daran denkt, in die Entwurfsansicht, hagelt es dann Fehlermeldungen, die im normalen Ablauf gar nicht auftauchen würden, wäre der Code schon komplett. Hab’s damit schon geschafft mir die DB zu zerschießen. (Keine Angst ist ja Test^^)


Und es muss ja auch nicht unbedingt Commandbars werden, mir ist egal mit welcher Methode, wenn jemand eine andere weiß. Hauptsache ich kann diese Beiden Buttons ansprechen bzw. abfragen ob diese gedrückt wurden. Bzw. halt so, dass beim Umschalten in die Entwurfsansicht und beim Zurückwechseln in die Formularansicht eben kein Code ausgeführt wird.


@ ebs17

Wie gesagt ich bin kein Programmierer. Ich weiß dass die MsgBoxen nicht ideal sind. Aber wie soll man sonst alles gleichzeitig auf den Schirm haben. VBA Code der abläuft, wissen welches Event gerade feuert, wissen wie zu diesem Zeitpunkt manche Variablen lauten und eventuelle Ablauffehler entdecken.

Damals mit VB in der Schule bin ich wesentlich besser zurechtgekommen.
Da war’s ja aber auch so, das da kein Access dahinter war, das alle meine Überlegungen zu Nichte macht. Da sobald man auch nur zwischendrin den Fokus woanders hinschiebt, kann’s passieren, dass der komplette Ablauf sich wieder ändert, weil auf einmal die Reihenfolge der Events sich mitändert bzw. weil Access durch Einstellungen selbst einen gewissen Ablauf vorgibt, der sich mit dem beißt, den man sich gerade hat einfallen lassen.

 

Hallo,

Du könntest statt dessen es auch mal mit Debug.Print versuchen,
oder eine Logtabelle befüllen.
Bedingte Kompilierung ist natürlich auch eine Option
(Luftcode)
Code:

Passende Ereignisse zum Setzen des Wertes sind wahrscheinlich .Open und .Close.
Auf jeden Fall geht es manuell im Direktfenster mit RunCode=Wert.
Vielleicht kann man sogar den View-Status des Forms über die Konstante acFormView
ermitteln. Da müssten allerdings die Profis was dazu sagen.

gruss ekkehard

 

Es ist sicher nicht nur auf Access beschränkt, dass man die verwendete Programmierumgebung verstehen und sich ihren Möglichkeiten anpassen sollte. Das Umgedehte wird nicht passieren.

Man könnte per Debug.Print Ausgaben in den Direktbereich leiten. Da läuft eine Prozedur wenigstens durch. Wie gesagt: Programmierstil Nachfolgemaßnahmen

 

Hatte ich als aller erstes probiert. Von hier: https://msdn.microsoft.com/de-de/vba...roperty-access

(Und etliche andere Seiten)

Mit Wechsel in die Datenblattansicht und wieder zurück funktioniert das wunderbar.

Beim Wechsel in die Entwurfsansicht aber dann nicht mehr. Problem ist, dass er immer 1 zurückgibt. Habe mich dann gefragt: "wie soll er 0 (Entwurfsansicht) zurückgeben, wenn in der Entwurfsansicht ja kein Code ausgeführt wird." Also bei welchem Ereignis das Abfragen ? Sobald das UFO geschlossen (Letzte Ereignis beim Wechsel in die Entwurfsansicht) ist ja nix mehr mit Code ausführen. Und bis zu diesem Zeitpunkt gibt er ja 1 zurück, weil er sich ja noch in der Formularansicht befindet.
Sobald man ja wieder in die Formularansicht wechselt (Erstes Ereignis UFO Form_Open), was ja der erste Zeitpunkt wäre wo wieder Code ausgeführt wird, gibt er ja 1 zurück, weil das Formular ja dann wieder in der Formularansicht ist.

Wobei ich gestehen muss die allererste Zeile check ich net. Alles andere ist verständlich.

"GetCurrentView Me, "Please contact system administrator.""


Bedingte Kompilierung mal auf die Schnelle angeschaut:

https://msdn.microsoft.com/de-de/vba...else-directive

und

http://www.*************************420340_0_0_asc.php


Dabei stellt sich aber auch wieder folgende Problematik: So wie ich das da raus lese, brauche ich Konstanten die ich dann Abfrage oder ? Und selbst wenn nicht brauche ich trotzdem eine Variable oder irgendeinen Anhaltspunkt um zu fragen #If Entwurfsansicht #Then also selbe in Grün. Ich muss wissen wie der Zustand ist um auf irgendwas zu prüfen.


Und zur Sache mit dem Direktfenster:

Ich will ja beim Testen sehen was im Formular geschieht. Ich will testen ob beim Klicken das richtige passiert oder ob der Fokus auch da landet wie ich mir das vorstelle. Das Direktfenster mag ja ok sein wenn ich nur sehen will ob in einer Funktion die Variable gesetzt wird oder Ähnliches. Aber mir den kompletten Ablauf im Formular nur übers Direktfenster mir "virtuell" vorstellen. Nein also das übersteigt mein Hirnschmalz *rolleyes.gif*

Ich wollte jetzt eigentlich nicht die nächsten 2 bis 3 Jahre VBA Programmierung lernen, damit ich ja alles richtig mache.
Ich bin gerade dabei zu versuchen wie was zu machen ist. Nur solange muss ich halt mit den Sachen die ich zur Verfügung habe auskommen. Und ich werde sicherlich nicht mir VBA bis zur Vergasung zu Gemüte führen. Ich übernehme hier nur Sachen für einen gewissen Zeitraum, bis Programmierer da sind. Weil wie gesagt würde ich jetzt VBA komplett versuchen zu verstehen, dann würde das sicher nicht in 2 bis 3 Monaten funktionieren. Im Moment beschränkt sich das eher auf:

"Ah das ähnelt meiner Problemstellung. Code Schnipp und versuchen anzupassen."


Weil von hier https://access-programmers.co.uk/for...d.php?t=277100 zum Beispiel:

Das wäre ja schon fast das was meinem Problem ähnelt. Problem ist nur wie das ummünzen, weil hier wird ja wieder ein eigenes Kontextmenü erstellt.

Aber wenn ich dort sehe, wird ja auch die Entwurfsansicht mit der ID=2952 (und Formularansicht mit ID=502) einem Control zugeordnet und anhand dieser vergeben ID bzw dem Commandbutton Control dann gefragt OnAction mache dies und das.

Also muss das doch auch irgendwo einzubauen gehen, nur eben ohne eigenes Kontextmenü und ohne eigenen Button darin.


Oder eventuell ist hiervon irgendwas verwendbar https://msdn.microsoft.com/de-de/vba...roperty-office

https://msdn.microsoft.com/de-de/vba...eration-office



P.S Jetzt kann ich die Verwirrung verstehen. Ich hab mir meinen Eingangspost mal druchgelesen. Das sind 2 verschiedene paar Stiefel. Das eine war ich hab daheim angefangen mit Access. Und das andere ist ich bin hier in ner kleinen Firma die grad im Aufbau ist. Und da kein anderer Depp da ist außer ich sollte ich halt mal so auf die Schnelle ne DB erstellen. Deswegen auch Formulare so wenig wie möglich Steuerelemente und Buttons. Da hier nur ein paar Hansle sind die von Computern mal so gar keine Ahnung haben. Und ich werd sicherlich nicht auch noch Daten in die DB klopfen. Irgendwann hört der Spass auch mal auf. Und solange keine Programmierer hier sind, wird das mehr oder weniger nur eine "Provisorische Produktiv DB"

 

Hallo,
Tja, habe das mit der bedingten Kompilierung mal ausprobiert, scheint
aber nicht zu funktionieren.
@Regulars
Geht das so grundsätzlich nicht, oder habe ich das falsch gemacht?

Also die Property angelegt wie in #19 und in einem Formular
Code:

Die Property hat jeweils den richtigen Wert (sollte wohl), aber die MsgBox beim
Öffnen poppt nicht auf; - der Code geht nach der Zuweisung direkt zum End Sub.
Das Gleiche übrigens auch bei Form_Load.

gruss ekkehard

 

Anbei ein kleines Beispiel, ist halt doch einfacher.
Es wird rein der Wechsel in die Entwurfsansicht berücksichtigt.
LG Markus

 

\@Beaker,
ich nehme an die bedingte Kompilierung funktioniert nur mit Konstanten, so wie in der VBA Hilfe beschrieben.

 

Hallo Markus,
OK, das hatte ich nicht nachgelesen; - schade.
Aber wenn dein Beispiel nun keine Lösung für den TS ist,
weiss bestimmt auch sonst keiner weiter.
gruss ekkehard

 

Gerade die ersten Schritte bei der Entwicklung einer Datenbank sollten von sehr viel Sachverstand begleitet werden, sonst kann es teuer werden, siehe Sonstiges - Es war einmal eine kleine Exceltabelle ...

 

Moin,

Die Idee, den Wechsel von der einen Sicht in die andere abzufangen führt auf einen Holzweg: Access kriegt die Absicht vor Dir mit, macht das, was es in dem Fall zu tun gedenkt und gibt danach die Kontrolle zurück. Das ist nun mal das Wesen der ereignisorientierten Programmierung.

 

\@ drambeldier

Wie jetzt versteh nur Bahnhof...

Ich hab mir das Beispiel gezogen, ausprobiert und ohne den Code jetzt genauer zu betrachen, wollt ich schon Juhuh schreien und vor markusxy auf die Knie fallen. *top *Sun *five

Aber wenn ich deine Aussage lese ????. Kann man den Code nun so verwenden bzw. kann ich den für mich anpassen oder geht da wieder was nicht ? *boah

Werd da grad net nicht schlau aus deiner Aussage...

Also bevor ich jetzt da alles anpasse um dann festzustellen das da doch ein Haken ist ?


@ ebs17

Jo hab das meinem Chef auch gesagt. Das ich das sicherlich irgendwie "hinfriemel". Aber er soll sich keine Illusion machen, das die dann im Hauptgeschäft verwendbar ist^^(So fürn Anfang fürn paar Adressen und Telefonnumern aber zu mehr auch nicht). Da solle er sich dann lieber ein gescheites CRM Programm zu legen. Ich bin mal gespannt, ob da dann wirklich eine "Neue" DB gemacht wird wenn denn mal in ferner Zukunft doch mal ein paar fähige Porgammierer hier anfangen. Weil ich mit sicherheit weiß, dass da dann noch Etliches mehr gemacht werden soll, als ein paar Adressen verwalten.


@ markusxy

Ich würde gerne noch warten mit dem auf die Knie fallen, was drambeldier damit meint.

Aber nichts desto trotz bedanken tue ich mich auf alle Fälle erstmal bei dir. Schon allein für die Mühe und ich werd nicht dümmer dabei, wenn ich mir das mal zu Gemüte führe.

@ Alle

Kann mir eventuell jemand erklären warum das nicht so geht wie es MS da auf Ihrer Seite beschreibt ? Also denk ich da richtig bei meiner Erklärung oder funktinoiert das eventuell auch und ich hab da eventuell was falsch beim Aufruf gemacht oder wie auch immer ?


Zitiere mich mal selber

 

Es geht dabei um das Timing.

Im Prinzip ist es so:
Der Befehl für den Wechsel in den Entwurf wird gegeben.
Jetzt gibt es mehrere die auf diesen Befehl lauschen.
Die Frage ist jetzt wer zuerst davon erfährt.

Im Prinzip kannst du es an der Reaktion des Codes erkennen.
Das Event im Code wird ausgelöst, bevor sich das Formular schließt.
Alles andere würde wenig Sinn machen. So viel zu der Aussage von Ralf.
Also gehe ich mal davon aus, dass das Event im Form zuerst an der Reihe ist.

Zum Herumtesten kann das tatsächlich eine Hilfe sein.
Ist aber nur eine Spielerei.

Es funktioniert aber nur dann richtig, wenn du über das Kontextmenü der Maus in den Entwurfsmodus wechselst.
In meinem Beispiel verwende ich ja ein Popup Form.

Bei einem Popup erscheint im Ribbon keine Möglichkeit zum Wechseln - zumindest bei Access 2007. Ein Ribbon Event kann ich bei Access 2007 per VBA nicht abfangen.

 

Sodala wieder da.

Hab da mal bissl rumgespielt mit dem Biespiel von Markus und bissl umgebaut *grins

Also als erstes:

** Vor markusxy offiziell auf die knie fall ***hands *top *five


Weil es funktinoiert.


Wermutstropfen:

Ich muss genau wissen, welches Event, dass ausführbaren Code enthält, als aller letztes triggert, um dann dort *** IsEntwurfClick *** auf False zu setzten.

Damit jeglicher Code bis zu diesem letzten Event auch nicht ausgeführt wird.

Außerdem wäre es nice wenn man den Code von Markus irgendwie in ein Klassenmodul bringen könnte, damit das Accessweit gilt und nicht nur an ein Formular gebunden ist.

Aber da hats bei mir dann aufgehört, da reicht mein Wissen einfach nicht aus das hinzubekommen.

Wollt zuerst einfach aus dem Private WithEvents Public machen und in ein Modul packen, aber Pustekuchen^^


Oder gibts eventuell irgendeine Mehtode abzufragen, ob noch Code ausgeführt wird, damit man weiß jetzt ist das Formular komplett da und es kommt kein weiterer Code mehr der ausgeführt wird. Weiß nich wie ich das ausdrücken soll^^

Weil so muss ich ja wieder mit den MsgBoxen ermitteln, was denn nun das wirklich letzte Event ist das triggert (und Code enthält)


Außerdem geht das nur wenn man das HFO öffnet. Sobald man das UFO alleine ohne das HFO öffnet, gehts natürlich nicht da ja der Code im HFO plaziert ist. Schon allein deswegen wäre es echt genial das Accessweit verfügbar zu machen. Ich könnte natürlich den selben Code nochmal ins UFO packen. Aber da weiß ich nicht ob sich da dann nicht irgendwas beißt zwischen HFO und UFO.

Aber hier mal mein Experiment. Einfach das HFO öffnen sich die MsgBoxen anschauen. Dann mit Rechtsklick im Formular (oder oben mit Rechtsklick beim Formularnamen) auf Entwurfsansicht. Beim Starten und Schließen wird der Code ausgeführt und beim Wechsel in die Entwurfsansicht und beim Wechsel in die Formularansicht nicht mehr.