Office: (Office 2010) Betätigung eines Makrobuttons während man noch Zelle editiert

Hallo Leute, ich habe ein Problem da weiß ich nicht mal so richtig wie ich es in Kürze beschreiben soll!

Ich habe da diese Excel xlsm Arbeitsmappe (nutze v2010), die mit mehreren Makros versehen ist.
Unter anderem frage ich bei einem Sheet 'X' ab, ob es gerade verändert wurde:

Private Sub Worksheet_Change(ByVal Target As Range)
...

Auf diesem Sheet 'X' wiederum gibt es einen Formularsteuerelementebutton 'Exit'.
Wenn gedrückt und etwas auf der Seite verändert worden ist (ich setze ein internes Flag bei jeder erkannten Änderung), frage ich nach, ob die Änderungen gespeichert werden sollen, speichere dementsprechend ggf., lösche die Eingabefelder wieder, springe auf eine andere Seite und verstecke dieses Sheet 'X' (wieder) (xlSheetVeryHidden).

Klappt soweit so gut.


Mein Problem beginnt dann, wenn jemand gerade etwas in eine Zelle auf Sheet 'X' schreibt und - ohne eine andere Zelle anzuklicken - quasi live aus dem Editiermodus in dem er noch ist auf den Exit-Button klickt.
1. wird >jetzt< die Worksheet_Change - Prozedur noch >nicht< durchlaufen - die Änderungen also in der Exitprozedur nicht bemerkt (und damit mein internes Flag zur Abfrage beim Verlassen nicht gesetzt) und dadurch ggf. nicht gespeichert und - schlimmer noch -
2. >nach< vollständiger Abarbeitung des Exit-Codes dieses Change-Ereignis aber dann ausgelöst.

Da die Seite jetzt versteckt ist (und alle Felder dort von mir bei Exit gelöscht wurden) kommt es zu einer Fehlermeldung, weil mein Worksheet_Change - Code nichts mehr findet (alle Felder leer).

Meine Fragen sind:
- Kann man irgendwie in VBA erkennen, dass gerade eine Zelle bearbeitet wird?
- Kann man per VBA diesen Modus ggf. verlassen (und damit auch das Change-Ereignis gleich auslösen)?
- Wenn nicht, was sonst könnte ich tun?

Ist ein seltsames Problem. Kommt selten vor, da die Bediener meistens vor dem Verlassen woanders hinklicken..
Aber wenn, könnte ich zwar den Fehler unterdrücken, die Eingabe in dieser Zelle wäre aber verloren gegangen.

Weiß jemand Rat?

 

Hallo Peter,

ich vermute, man muss sich Deinen Code im Einzelschrittmodus anschauen, und herausfinden wo und wie genau die von Dir gewünschte Reihenfolge in den Mkros eingehalten werden kann.
Liegt meines Erachtens an den Ereignissen.
Dafür brauchts aber eine Beispieldatei mit Deinem Code zum testen und nachvollziehen.
;O)

 

Hallo Achim,

2. Versuch - ich hatte hier schon einen Roman für dich geschrieben aber beim Hochladen des Anhangs gabs einen Timeout und alles war weg :--(((

Anyway - ich habe alles in der xlsm-Datei beschrieben...

 

Hallo Peter,

mir ist nicht bekannt, dass es eine RANGE-Methode gibt, die den Editier/Modifikationsstatus einer Zelle feststellen ließe.

In der beiliegenden Excel-Datei habe ich Folgendes eingebaut:
Da du die Activate-Methode verwendest, um zwischen den Arbeitsblättern umzuschalten, habe ich die damit verbundenen Events benutzt, um über die Event-Behandlungsroutinen "Worksheet_Deactivate" und "Worksheet_Activate" im Codemodul für "ShtForm" die Änderungsprüfung einzubauen.

Du befindest dich normalerweise im Arbeitsblatt "Hauptseite". Sobald du mittels "ShtForm.Activate" von "ShtMain" zu "ShtForm" wechseln möchtest, werden nacheinander die beiden Ereignisse "ShtMain_Deactivate" und "ShtForm_Activate" ausgelöst. In der Behandlungsroutine "Worksheet_Activate" für "ShtForm" habe ich dein normales Kopierprozedere zum Vorbelegen von "ShtForm" verschoben und darüber hinaus in ein sog. "Zwischenlager" in einem freien Blattbereich die editierbaren Zellwerte ein 2. Mal kopiert.
Wird nun die "btnExitForm_Click"-Prozedur ausgeführt, wird überprüft, ob im Arbeitsblatt "ShtForm" der editierbare Bereich sich vom "Zwischenlager"-Bereich unterscheidet: Ist das der Fall, wird die globale Variable "blnFormModified" auf TRUE gesetzt und damit dein Problem in der "Worksheet_Change"-Event-Behandlungsroutine behoben.

Um die Abfolge der Activate/Deactivate-Events zu zeigen, habe ich ein paar MsgBox-Anzeigen eingebaut. Diese können natürlich wieder entfernt/auskommentiert werden.
Darüber hinaus habe ich auch eine Reihe von "Application.EnableEvents=False/True" Anweisungen eingefügt, um zu verhindern, dass bei jeder Arbeitsblattänderung das "Worksheet_Change"-Event ausgelöst wird - insbesondere in der Behandlungsroutine dieses Events.

 

Hallo Anton,

erst mal vielen Dank, dass du dich meines Problems angenommen hast!

Die prinzipielle Idee eine Kopie der Daten anzulegen hatte ich auch schon.
Problem: Die meisten Daten entstammen einer Datei mit nach oben offener Anzahl von Einträgen.
Es war mir einfach unsympathisch, (wegen dieses blöden und seltenen Problems) alles 2x abzulegen. Geht aber natürlich.

Man muss also immer alles vergleichen, wenn beim Verlassen von shtForm blnFormModified nicht gesetzt ist.
Warum verlagerst du das in die Worksheet_Activate und Worksheet_Deactivate Subroutines? Das habe ich nicht verstanden.
Man könnte dies dann doch auch gleich in der Sub des Exit-Buttons tun?

Das falsche Change-Ereignis kann man dann bei Auftreten (während man schon in einem anderen Sheet ist) leicht erkennen und ignorieren.

Wie gesagt - eine unschöne Lösung, finde ich...
Es könnten hunderte Daten sein, die ich 2x ablegen muss wegen dieses blöden Verhaltens.

Deshalb hoffte ich, einen Weg zu finden, das abzufangen.


Ich arbeite eigentlich nie mit "Application.EnableEvents=False/True", belege stattdessen ein globales Flag 'blnInMacro' oder so, dass ich in den Event-Routinen abfrage und dann ggf. die Routine gleich wieder verlasse.
"EnableEvents" ist natürlich eleganter.
Ich befürchte damit aber die Probleme zu mehren, die ich mit den Application.ScreenUpdating=FALSE - Anweisungen jetzt schon habe:
Beim Entwickeln des Programms bricht man immer mal wieder den Code ab um etwas zu verändern und wie oft muss ich erst wieder einen Hilfsmakro starten, der das Screenupdating wieder einschaltet. Solche Problem könnten sich mit "EnableEvents" vermehren, dachte ich.
Variablen werden dagegen bei Codeänderung mit Recompilierung gelöscht.

Grüße,
Peter

 

Hallo Peter,

bei mir daheim gibt es ein Sprichwort: "Viele Wege führen nach Rom." Das gilt insbesondere ganz gewiss in der Programmiererzunft. Und alle diese verschiedenen Wege habe ihre Vorteile - und ganz gewiss auch ihre Nachteile. Man muss eben abwägen.

Darüber hinaus wolltest du speziell wissen, warum ich einiges in die Callback-Routinen für die Events "Worksheet_Activate" bzw. "Worksheet_Deactivate" verlagert habe:
Dein spezielles Problem war ja, dass in bestimmten Fällen die Variable "blnFormModified" zu spät aktualisiert wird (auf TRUE gestellt wird). Daher war mein Gedanke, ich muss alles tun, um möglichst bald den Mechanismus, der zur Überprüfung auf Datenveränderung notwendig ist, zur Verfügung zu haben. Der frühestmögliche Zeitpunkt ist die Aktivierung des betreffenden Arbeitsblattes. Nach diesem Zeitpunkt muss man damit rechnen, dass ein User alles Mögliche tun kann, um eine Änderung an den Daten im (bereits) aktivierten Blatt zu erreichen (wie du ja leidvoll weißt).
Ich wusste natürlich nicht, wie dein reales Problem gelagert ist. Daher habe ich die paar Zellen des Beispiels in einem unbenutzten Bereich zwischengespeichert.

Ein weiterer Gedanke, der mir gerade kommt, ist: Ist es wirklich notwendig zu überprüfen, ob der User an den Daten eine Veränderung vorgenommen hat? Kann man nicht etwa von der Annahme ausgehen, dass der User die Daten auch mit hoher Wahrscheinlichkeit ändert, da sie ihm zur Änderung angeboten werden? Ich weiß es natürlich nicht - vielleicht ist die dann nötige Aktualisierung weiterer Daten wirklich so zeitraubend/umständlich etc., sodass die Überprüfung auf Datenveränderung tatsächlich notwendig/sinnvoll ist - oder kann die Überprüfung doch entfallen angesichts der Probleme, die mit ihrer Implementierung einhergehen?

 

Hallo Anton,

ja, es ist ungünstig immer zu Speichern.
Man kann in der Form auch Dinge nur ansehen und andere Sachen damit auslösen - ohne dabei etwas zu verändern.

Mittlerweile hatte ich bemerkt, dass Letzteres nun die Anwendbarkeit deiner Lösung wieder auf 0 setzt :--(

Mit anderen Buttons im Sheet und mit einer Userform bei RechterMaustate, sowie einer Aktion bei Doppelklick (auf jeweils bestimmte Zellen) wird >auch< immer Workbook.Saved = FALSE gesetzt, obwohl eigentlich nichts verändert wird - aus die Maus...

In einem anderen Forum hat mir tatsächlich jemand einen Link geschickt, der beschreibt, wie man u. a. erkennen kann, ob man im Editiermodus ist (Viele Möglichkeiten im Ribbon werden dann ja grau - das kann man abfragen).
Leider - hat er gleich beigefügt - hilft das nichts, weil bei Ausführung des Exit-Makros dasselbe passiert ...

Ich glaube ich muss da aufgeben.
Habe im Moment eine Msgbox in die Worksheet_Change - Prozedur der Form geschrieben, die im Falle, dass man gerade nicht mehr in diesem Sheet ist meldet, dass die letzte Eingabe ggf. verloren ist und wie man es in Zukunft richtig machen muss.

Lösung B) halt ...

Greetz, Peter

 

Hola,

und warum schreibst du in beiden Foren nicht, wo dir noch geantwortet wird?

Gruß,
steve1da

 

Hi Steve,
auch dir ein herzliches ¡Hola!

Ich bin nicht sicher, ob ich deine Frage richtig verstehe, aber hier sind die threads aus den zwei anderen Foren:
http://www.excel-werkstatt.de/n_forum/viewthread.php?boardid=11&thid=9197
http://www.herber.de/forum/messages/1449538.html

Letztendlich gab es ja keine Lösung, was soll ich also kreuz und quer übertragen?

Ich wusste nicht, ob ich hier auf andere Foren verlinken darf/soll ..

Le pido perdón!

 

Hola,

durch das Verlinken ermöglichst du den Helfern andere Lösungen zu sehen, damit diese nicht unnötig arbeiten oder vielleicht auf den anderen Lösungen aufsetzen können.

Gruß,
steve1da