EnableEvents und ScreenUpdating funktionieren nicht
Olaf Gerecke
ich verzweifle grade an einem (mir) unerklärlichen Phänomen.
In einem umfangreichen Excel-VBA-Projekt (Größe der XLA z.Zt. ca. 2,6 MB)
habe ich - nicht immer, aber leider viel zu oft - den Effekt, dass nach den
Zeilen
Application.ScreenUpdating = False
Application.EnableEvents = False
beide Eigenschaften immer noch auf 'True' stehen.
Manchmal werden sie auch kurzzeitig auf 'False' gesetzt, werden aber bei
Ausführung der nächsten x-beliebigen Codezeile wieder umgesetzt.
Ich behelfe mich z.Zt. mit hunderten von Schaltern, die für einen sofortigen
Aussprung aus den Event-Routinen sorgen, wenn diese nicht durchlaufen werden
dürfen. Aber das kostet Nerven, Arbeit und vor allem Performance. Und
ScreenUpdating sorgt für irres Geflacker bei umfangreichen makros-seitigen
Umgestaltungen von Worksheets.
Der Effekt tritt unabhängig davon auf, ob die zu bearbeitenden Worksheets
grade Protected oder Unprotected sind.
Kennt jemand eine mögliche Ursache für dieses Phänomen bzw. einen Kniff, wie
ich das in den Griff bekomme?
Lieben Dank im Voraus,
Olaf Gerecke
Dr. Eckehard Pfeifer
genau so monstroes wie 2,6 MB. Waere es nicht denkbar, die Dinge als
COM-Add-In zu schreiben und die Steuerung nicht unbedingt Excel allein zu
ueberlassen?
Fuer was genaueres muesste man schon im Projekt drin stecken. Manipulationen
lassen sich ja auch ohne Screen (also bei ausgeblendeten Blaettern umsetzen)
und manches mehr.
--
MfG EP
Entwicklung - Beratung - Training
(Microsoft Certified Application Developer)
www.dr-e-pfeifer.net
--
Microsoft Excel Funktionsverzeichnis, ISBN 3860636898
Microsoft Excel Programmier-Rezepte, ISBN 386063089X
Microsoft Office PowerPoint 2003 - Das Handbuch, ISBN 3860631942
Microsoft Office Excel 2003 - Das Handbuch, ISBN 3860631934
Olaf Gerecke
selbstverständlich nutzen wir auch Com-Add-Ins.
Die 2,6 MB XLA bilden nur den kleinsten Teil dieser Programm-Moduln, die
sich einfach nicht mehr aus der .NET-Applikation heraus erledigen lassen.
Insgesamt handelt es sich halt um ein etwas größeres Projekt.
Allein in den Teil des Schriftverkehrs mit Excel sind bislang ca. 6 bis 7
Mannjahre Arbeit geflossen, ins Gesamt-Projekt ca. 35 Jahre.
Kleiner geht's nicht.
Ein für den professionellen Einsatz gemachtes Office-Werkzeug solte das
abkönnen.
Dank & Gruß,
Olaf Gerecke
"Dr. Eckehard Pfeifer" schrieb:
Dr. Eckehard Pfeifer
wie beim Arzt mit den Ferndiagnosen...
Thomas Ramel
Olaf Gerecke schrieb am 26.01.2006
> ich verzweifle grade an einem (mir) unerklärlichen Phänomen.
> In einem umfangreichen Excel-VBA-Projekt (Größe der XLA z.Zt. ca. 2,6 MB)
> habe ich - nicht immer, aber leider viel zu oft - den Effekt, dass nach den
> Zeilen
>
> Application.ScreenUpdating = False
> Application.EnableEvents = False
>
> beide Eigenschaften immer noch auf 'True' stehen.
>
> Ich behelfe mich z.Zt. mit hunderten von Schaltern, die für einen sofortigen
> Aussprung aus den Event-Routinen sorgen, wenn diese nicht durchlaufen werden
> dürfen. Aber das kostet Nerven, Arbeit und vor allem Performance. Und
> ScreenUpdating sorgt für irres Geflacker bei umfangreichen makros-seitigen
> Umgestaltungen von Worksheets.
>
> Kennt jemand eine mögliche Ursache für dieses Phänomen bzw. einen Kniff, wie
> ich das in den Griff bekomme?
Screenupdating = False/True ist bei entsprechender Programmierung obsolent
und bringt kaum noch Vorteile.
Das heisst im Speziellen, dass komplett (bis zu 99% ist das machbar) ohne
.Select und .Activate programmiert wird.
Ich bin mir nicht sicher, ob dies so umgesetzt ist, kann mich ob des
geschilderten Aufwandes aber auch täuschen.
Einige Hintergründe dazu werden auf der folgenden Seite geschildert:
http://www.herber.de/xlfaq/xlbasics/main_sel.htm
Eine weitere Ursache für solche Vorkommnisse könnte auch eine korrupte
Mappe, sprich AddIn sein. Hier wäre es sinnvoll, der Programmier-Müll ab
und zu zu entsorgen, indem die Module in eine neue Mappe umgesetzt werden.
Ein dabei hilfreiches Tool findest Du hier:
http://www.appspro.com/Utilities/CodeCleaner.htm
Mit freundlichen Grüssen
Thomas Ramel (@work)
--
- MVP für Microsoft-Excel -
[Win XP Pro SP-2 / xl2003 SP-1]
Microsoft Excel - Die ExpertenTipps:
(http://tinyurl.com/9ov3l und http://tinyurl.com/cmned)
Bruno Uato
Hallo,
deine Schilderung läßt mich vermuteten das du eben irgendwo vergisst,
den Schalter wieder umzulegen. Zudem würde ich vermuten das das Design
deiner Anwendung vielicht überprüfungswürdig ist.
Aber um der Fehlerquelle auf die Schliche zu kommen, würde ich
debug.print etc. einsetzen um den Programmablauf nachvollziehen zu
können.
Mfg, Bruno
Olaf Gerecke
meine Aussage bezieht sich doch auf meine Ergebnisse beim Debuggen.
Nach Ausführung der nächsten Codezeile nach dem "Application.EnableEvents =
False", auch wenn diese nur heißt "x = y", ist der Schalter wieder auf "True".
Da wird nicht zwischenzeitlich anderswo was umgesetzt.
Das Design einer Anwendung ist grundsätzlich immer "überprüfungswürdig".
Aber was meinst Du konkret?
Gruß, Olaf
"Bruno Uato" schrieb:
Olaf Gerecke
damit hast Du freilich recht.
"Select" und "Activate" sind auch bereits weitgehend eliminiert, nur noch
nicht vollständig. Ich bin aus zeitlichen Gründen noch nicht dazu gekommen,
sämtliche Altlasten meiner Vorgänger umzuschreiben. Wie gesagt: Es ist ein
etwas umfangreicheresw Projekt.
Nichts desto trotz:
EnableEvents und ScreenUpdating sollten funktionieren. Tun sie aber einfach
nicht.
Hat noch irgendwer Ideen, woran das liegen kann?
Dank und Gruß,
Olaf
"Thomas Ramel" schrieb:
> Screenupdating = False/True ist bei entsprechender Programmierung obsolent
> und bringt kaum noch Vorteile.
>
> Das heisst im Speziellen, dass komplett (bis zu 99% ist das machbar) ohne
> ..Select und .Activate programmiert wird.
Thomas Ramel
Olaf Gerecke schrieb am 27.01.2006
> "Select" und "Activate" sind auch bereits weitgehend eliminiert, nur noch
> nicht vollständig. Ich bin aus zeitlichen Gründen noch nicht dazu gekommen,
> sämtliche Altlasten meiner Vorgänger umzuschreiben. Wie gesagt: Es ist ein
> etwas umfangreicheresw Projekt.
>
> Nichts desto trotz:
> EnableEvents und ScreenUpdating sollten funktionieren. Tun sie aber einfach
> nicht.
Dann bearbeite eine Kopie (!!) deiner Mappe mal mit dem CodeCleaner - ich
vermute stark, dass da einiges an 'Leichen' rumhängt, die dann solches
veranlassen können.
Heinrich Woick
> Nach Ausführung der nächsten Codezeile nach dem "Application.EnableEvents =
> False", auch wenn diese nur heißt "x = y", ist der Schalter wieder auf "True".
> Da wird nicht zwischenzeitlich anderswo was umgesetzt.
> Das Design einer Anwendung ist grundsätzlich immer "überprüfungswürdig".
> Aber was meinst Du konkret?
Ich sehe zwei Möglichkeiten:
Entweder Du postest mal die betreffenden 10 Zeilen Code, in denen Du den
Fehler lokalisierst.
Noch besser: Du suchst Dir einen intelligenten Menschen in Deiner
Umgebung und erklärst ihm/ihr das Problem anhand der Listings Zeile für
Zeile. Besonders die Stellen erklären, in denen der Fehler NICHT stecken
kann, weil Du ja alles schon untersucht hast. Ein einfaches Hausrezept,
sollte eigentlich nicht länger als eine halbe Stunde dauern.
Heinrich Woick
Olaf Gerecke
wir haben schon viele "halbe Stunden" mit bis zu fünf recht intelligenten
Köpfen vor dem VBA-Debugger gehockt und sind aus dem Staunen nicht mehr
rausgekommen...
Hier mal eine von hunderten Code-Passagen, in denen das Phänomen immer mal
wieder - aber nicht immer in gleicher Weise - auftritt:
Public Sub Formatieren()
Dim wsE As Worksheet
On Local Error Resume Next
Application.ScreenUpdating = False
Application.EnableEvents = False
Set wsE = Workbooks(2).Worksheets(1)
Select Case wsE.Range("DB_anz_Einheit").value
Case 1: wsE.Range("Einheit").value = 1
Case 100: wsE.Range("Einheit").value = 2
Case 1000: wsE.Range("Einheit").value = 3
Case Else: wsE.Range("Einheit").value = 4
End Select
...
...
End Sub
Nach Ausführung der Zeile 4 der Sub (Application.EnableEvents = False) steht
im Überwachungsfenster:
"Application.EnableEvents = False"
"Err.Number = 0"
Nach Ausführen der Zeile 5 (Set wsE = Workbooks(2).Worksheets(1)) steht im
Überwachungsfenster:
"Application.EnableEvents = True"
"Err.Number = 0"
Da gibt es keinen Fehler.
wsE ist eine gültige Worksheet-Instanz.
Und wie gesagt: Es geht um hunderte von Stellen dieser Art im Sourse-Code.
Mal wird nur EnableEvents umgesetzt, mal nur ScreenUpdating, meistens aber
beide. Oftmals ist auch schon nach Ausführung von Zeile 4 die Eigenschaft
EnableEvents immer noch "False".
Erklär mir das mal bitte.
Es geht hier nicht um irgendwelche Anfängerfehler im Makro-Code, sondern um
ein heftiges Problem von Excel-VBA, welches möglicherweise mit der Größe
meines Projekts zusammenhängt, vielleicht aber auch mit ganz etwas Anderem...
Das würde ich gern herausfinden, bzw. einen Weg finden das Problem zu lösen
oder zumindest zu umgehen.
Gibt es denn hier keinen, der sich wirklich in den Tiefen von Excel-VBA
auskennt, und nicht gleich dem Fragenden und Hilfesuchenden unterstellt,
einfach zu blöd zu sein?
Gruß,
Olaf
"Heinrich Woick" schrieb:
Olaf Gerecke
danke für den Tipp mit dem CodeCleaner.
Ein gutes Tool, dass mir sicher in anderen Fällen gute Hilfe leisten kann.
Im vorliegenden Fall leider nicht.
Es wurden 0 Zeilen exportiert und absolut nichts geändert (Ich habe zwar
nicht alle, aber zumindest die ersten 10 Moduln beider XLA's - Original und
Kopie - mit einem Diff-Tool gescannt).
Die Fehler bleiben.
Dank und Gruß,
Olaf
"Thomas Ramel" schrieb:
> Grüezi Olaf
Dr. Eckehard Pfeifer
Aber: Keiner haelt Dich hier fuer bloed und viele kennen sich durchaus in
"Tiefen" aus.
Das Beispiel in deinem Code ist insofern nicht sehr illustrativ. Vielleicht
erreicht Excel grade den Rand seiner Kapazitaet oder weiss der Teufel was.
Ein Fall fuer VBA ist der teil der Sub nicht unbedingt, da es (in diesem
Beispiel) vielleicht besser ist, entweder eine Wenn-Formel in
wsE.Range("Einheit") zu benutzen oder ein ausgeblendetes Blatt mit Werten
fuer SVERWEIS.
Wie oft wird eigentlich Resume Next eingesetzt? Wer weiss, was da unterwegs
passiert - von hier aus kann ichs nicht sagen, ich vertraue Dir da
vollkommen. Aber helfen kann ich so auch nicht...
Es ist bekannt, dass Excel seine Grenzen hat (die Website von Phillip von
Wartburg zeigts deutlich) und mehr als einmal haben viele von uns dabei
geflucht, dass Dinge nicht so laufen, wie mans denkt.
Olaf Gerecke
kleiner Flüchtigkeitsfehler meinerseit im letzten Beitrag.
Am Ende der anliegenden Text-Passeage muss es natürlich heißen:
'EnableEvents immer noch "True"'
Eindeutige Überarbeitungs-Folge. Ich btte um Entschudigung.
Olaf Gerecke
danke für Deinen Beitrag.
1.) Du hast freilich recht: Ferdiagnosen sind selten von wirklichem Nutzen.
Das sage ich meinen Anwendern auch immer wieder;-)
2.) Auf das Thema "niemand hält Dich hier für blöd" will ich Dir nur sagen:
Dich habe ich damit auch nicht gemeint.
3.) Mit "die Website von Phillip von Wartburg" meinst Du vermutlich
http://www.office-loesung.de. Auch hier bin ich bislang in dieser Sache nicht
fündig geworden.
4.) Auf "Es ist bekannt, dass Excel seine Grenzen hat" kann ich nur zurück
fragen:
Aber wo liegen die? Wo sind die dokumentiert? Warum veröffentlicht Microsoft
nicht die gegebenen Limitierungen und hilft den Anwendern dabei, sie zu
umgehen?
Kurz: Wo gibt es wirkliche Hilfe?
Ich fühle mich abermals - wie in vielen anderen Fällen schon seit über 20
Jahren - von Microsoft schlicht verarscht!
Erst wird einem versprochen, "alles sei möglich", dann investiert man Jahre
an Arbeit um all die vielen Möglichkeiten zu nutzen. Und am Ende muss man
dann feststellen, die zugrunde liegenden Office-Produkte funktioniert einfach
ab einem gewissen Punkt nicht mehr,... ohne jede Vorwarnung.
Diverse Projekte sind daran schon gescheitert, jede Menge Firmen darüber in
die Insolvenz geraten, tausende Arbeitsplätze wurden vernichtet, ... meiner
wird möglicherweise einer der nächsten sein ... weil allzu viele Leute
(völlig blind) voller Gottvertrauen (oder sollte ich sagen "voller
Gates-Vertrauen"), darauf bauen, dass Microsoft-Applikationen halten, was sie
versprechen.
Sie tun es nicht!
Ist das jetzt das Resüme?
Pech gehabt?
Zig Jahre Arbeit im Arsch?
Einreihen bei Harz IV?
Na, herzlichen Glückwunsch!
Noch mal: Gibt es irgendjemanden hier, der in der Lage ist eine konkrete
Hilfestellung anzubieten?
Das darf auch ruhig ein paar Euro kosten. Hauptsache wir kommen irgendwie
weiter. Bei einem vertrauenswürdigen Hilfeleister mit nachgewiesener
Kompetenz kann ich gern auch unsere gesamte Applikation (ein größeres
.NET-Projekt für die Druck-Industrie) installieren, ohne das die
untergeordenete Excel-Lösung eh nicht läuft. Ich bin dafür auch gern bereit,
bis zu 1000 km zu reisen (Ausgangspunkt: Niederrhein Deutschland) und mehere
Tage Zeit zu investieren, wenn es denn hilft.
Gibt es hier irgendwen, der sich an diese Aufgabe herantraut und glaubhaft
echte Hilfe versprechen kann?
Wenn ja, bitte melden!
Gruß,
Olaf
"Dr. Eckehard Pfeifer" schrieb:
Olaf Gerecke
ich bin eben nicht auf alle Deine Argumente eingegangen, z.B. Verwendung von
"SVERWEIS" anstelle meines Codes.
Aber, im Ernst: Das ist völlig nebensächlich.
Hier noch mal ein eigens konstruiertes Ober-Simpel-Beispiel dass ich bewußt
zum Testen eingefügt habe.
Private Sub Bullerbueh()
Dim x as Integer
Dim y as Integer
On Local Error Resume Next
x = 2
y = 1
Application.EnableEvents = False
x = y
End Sub
Spätestens bei der Zeile "x = y" steht "EnableEvents" wieder auf "True" !!!
Das ist bei mir im Debugger innerhalb meiner XLA jederzeit nachvollziehbar.
Err.Number = 0
Das ist doch einfach irre!
Was ist das für eine Applikation, die solch drastische Fehler zulässt -
unabhängig von der Größe der XLA ???
Ich kann nur noch mit dem Kopf schütteln !!!
Gruß,
Olaf
Dr. Eckehard Pfeifer
http://www.xlam.ch/xlimits/index.htm
Best wishes.
--
MfG EP
Entwicklung - Beratung - Training
(Microsoft Certified Application Developer)
www.dr-e-pfeifer.net
--
Microsoft Excel Funktionsverzeichnis, ISBN 3860636898
Microsoft Excel Programmier-Rezepte, ISBN 386063089X
Microsoft Office PowerPoint 2003 - Das Handbuch, ISBN 3860631942
Microsoft Office Excel 2003 - Das Handbuch, ISBN 3860631934
"Olaf Gerecke" <OlafG...@discussions.microsoft.com> schrieb im
Newsbeitrag news:CC2A0DA2-EC0C-42F3...@microsoft.com...
Melanie Breden
Olaf Gerecke schrieb:
> Hier noch mal ein eigens konstruiertes Ober-Simpel-Beispiel dass ich bewußt
> zum Testen eingefügt habe.
>
> Private Sub Bullerbueh()
> Dim x as Integer
> Dim y as Integer
> On Local Error Resume Next
warum verwendest du die Local-Anweisung, die es im Objektkatalog von VBA
gar nicht gibt, sondern ein Überbleibsel aus aus älteren Basic-Versionen ist?
> x = 2
> y = 1
> Application.EnableEvents = False
> x = y
> End Sub
>
> Spätestens bei der Zeile "x = y" steht "EnableEvents" wieder auf "True" !!!
> Das ist bei mir im Debugger innerhalb meiner XLA jederzeit nachvollziehbar.
> Err.Number = 0
> Das ist doch einfach irre!
>
> Was ist das für eine Applikation, die solch drastische Fehler zulässt -
> unabhängig von der Größe der XLA ???
> Ich kann nur noch mit dem Kopf schütteln !!!
Ich denke nicht, dass du die Schuld bei der Apllikation suchen solltest,
denn die arbeitet nur das ab was du programmiert hast.
Deine Beobachtung kann ich zudem nicht bestätigen:
Wenn ich den Befehl 'Application.EnableEvents' in das Überwachungsfenster ziehe,
ändert sich dessen Wert nach durchlaufen der Zeile im Code von True auf False
und wird in der nächsten Zeile nicht wieder zurückgesetzt.
Selbst bei einem erneuten Aufruf der Prozedur bleibt der Wert auf False und
das sol lange bis er explizit wieder auf True gesetzt wurde.
Hast du deine Testprozedur mal an einer jungfräulichen Datei getestet?
Mit welcher Excel Version arbeitest du?
Mit freundlichen Grüssen
Melanie Breden
--
- Microsoft MVP für Excel -
Microsoft Excel - Die ExpertenTipps http://tinyurl.com/cmned
Das Excel-VBA Codebook http://excel.codebooks.de
Excel-Auftragsprogrammierung
Heinrich Woick
> Gibt es denn hier keinen, der sich wirklich in den Tiefen von Excel-VBA
> auskennt, und nicht gleich dem Fragenden und Hilfesuchenden unterstellt,
> einfach zu blöd zu sein?
Es tut mir leid, daß ich diesen Eindruck vermittelt habe. Ich bin von
der Situation eines einzeln arbeitenden Programmierers ausgegangen, der
für seine eigenen Fehler mehr oder weniger blind ist, aber beim Erklären
des Problems gegenüber einem Dritten, der nicht mit der Aufgabenstellung
vertraut sein muß, plötzlich den Fehler selbst erkennt.
Da der Fehler in deinem kleinen Codebeispiel im Standalone-Test nicht
auftritt, liegt die Ursache wohl in der Komplexität Deines
Programmsystems. Und zwar zeitlich vor dem hier zitierten Code. Aber das
ist natürlich nur Spekulation von mir.
Heinrich Woick
Thomas Ramel
Olaf Gerecke schrieb am 28.01.2006
> Private Sub Bullerbueh()
> Dim x as Integer
> Dim y as Integer
> On Local Error Resume Next
> x = 2
> y = 1
> Application.EnableEvents = False
> x = y
> End Sub
Die Applikation scheint ein Faible für 'On Error Resume Next' zu haben,
ohne dass eine effektive Fehlerbehandlungs-Routine eingesetzt wird.
Diese Strategie ist vermutlich zu überdenken, wobei mir schon klar ist,
dass aus gewachsenen Strukturen solches gedeihen kann.
Mit generellen 'On Error Resume Next' kannst Du dir problemlos die
Fehler-Erzeugung in anderen Subs abmurksen, wie mir selber hier in der NG
schon gezeigt wurde.
Gezielt eingesetzt kann es Situationen geben, in denen die Verwendung
angebracht sein mag, generell sollten aber Fehler eingekreist und gezielt
abgefangen werden.
Auch dies weist IMO auf den Neuaufbau der XLA hin....
> Spätestens bei der Zeile "x = y" steht "EnableEvents" wieder auf "True" !!!
> Das ist bei mir im Debugger innerhalb meiner XLA jederzeit nachvollziehbar.
> Err.Number = 0
Das kann ich keineswegs nachvollziehen, genauso wie Melanie es schon sagte.
> Was ist das für eine Applikation, die solch drastische Fehler zulässt -
> unabhängig von der Größe der XLA ???
Hier steckt der Wurm wohl in der XLA oder der Mappe selbst drin.
Meine Empfehlung ist nach wwie vor, die XLA mit dem CodeCleaner zu
behandeln oder komplett neu aufzubauen (also Module exportieren und wieder
einlesen in eine neue Mappe; das macht aber auch der CodeCleander so).
Mit freundlichen Grüssen
Thomas Ramel
--
- MVP für Microsoft-Excel -
[Win XP Pro SP-2 / xl2000 SP-3]
Olaf Gerecke
"Melanie Breden" schrieb:
> Deine Beobachtung kann ich zudem nicht bestätigen:
> Wenn ich den Befehl 'Application.EnableEvents' in das Überwachungsfenster ziehe,
> ändert sich dessen Wert nach durchlaufen der Zeile im Code von True auf False
> und wird in der nächsten Zeile nicht wieder zurückgesetzt.
> Selbst bei einem erneuten Aufruf der Prozedur bleibt der Wert auf False und
> das sol lange bis er explizit wieder auf True gesetzt wurde.
Da hast Du freilich recht. In einem kleinen Standalone-Makro habe ich den
Fehler natürlich auch nicht, sondern nur im Zusammenhang mit meiner recht
großen XLA.
Das ist ja der Grund, warum ich frage.
Wo sind die nicht dokumentierten Limitierungen?
Oder: Unter welchen Bedingungen, die an völlig anderer Stelle im Source
gesetzt werden, funktiuoniert es, oder funktioniert es eben nicht?
> Hast du deine Testprozedur mal an einer jungfräulichen Datei getestet?
> Mit welcher Excel Version arbeitest du?
Ich selbst arbeite mit Excel 11 SP2. Bei unseren Anwendern ist das System im
Einsatz ab Excel 10 SP1 aufwärts.
Gruß, Olaf
Olaf Gerecke
"Thomas Ramel" schrieb:
> Die Applikation scheint ein Faible für 'On Error Resume Next' zu haben,
> ohne dass eine effektive Fehlerbehandlungs-Routine eingesetzt wird.
> Diese Strategie ist vermutlich zu überdenken, wobei mir schon klar ist,
> dass aus gewachsenen Strukturen solches gedeihen kann.
>
> Mit generellen 'On Error Resume Next' kannst Du dir problemlos die
> Fehler-Erzeugung in anderen Subs abmurksen, wie mir selber hier in der NG
> schon gezeigt wurde.
Da hast Du sicher recht, aber das tut eigentlich nichts zur Sache.
Ich kann 'On Error Resume Next' getrost weglassen.
Das Problem bleibt dasselbe.
> Gezielt eingesetzt kann es Situationen geben, in denen die Verwendung
> angebracht sein mag, generell sollten aber Fehler eingekreist und gezielt
> abgefangen werden.
> Auch dies weist IMO auf den Neuaufbau der XLA hin....
Das habe ich schon mehrfach gemacht.
Ohne Erfolg.
> > Spätestens bei der Zeile "x = y" steht "EnableEvents" wieder auf "True" !!!
> > Das ist bei mir im Debugger innerhalb meiner XLA jederzeit nachvollziehbar.
> > Err.Number = 0
>
> Das kann ich keineswegs nachvollziehen, genauso wie Melanie es schon sagte.
Siehe meine Antwort an Melanie.
> > Was ist das für eine Applikation, die solch drastische Fehler zulässt -
> > unabhängig von der Größe der XLA ???
>
> Hier steckt der Wurm wohl in der XLA oder der Mappe selbst drin.
> Meine Empfehlung ist nach wwie vor, die XLA mit dem CodeCleaner zu
> behandeln oder komplett neu aufzubauen (also Module exportieren und wieder
> einlesen in eine neue Mappe; das macht aber auch der CodeCleander so).
Ob mit dem CodeCleaner oder "zu Fuss".
Die Fehler sind anschließend wieder da!
Wenn ich meine XLA drastisch reduziere, indem ich nur 2 Moduln von insgesamt
20 übrig lasse, tritt der Fehler nicht mehr auf. Aber dann kann ich auch nur
noch einen von vielen Programmteilen unseres Systems benutzen, weil der Rest
fehlt.
Über eine generelle Splittung in viele kleine XLA's habe ich auch schon
nachgedacht.
Aber das würde äußerst arbeitsaufwendig werden und die Kontrolle von
Versionskonflikten bei unseren Anwendern ins Uferlose treiben.
Meine Frage ist: Gibt es bekannte Limitierungen und wo liegen die?
Oder: Welche größenunabhängigen Bedingungen an anderer Stelle können den von
mir festgestellten Effekt bewirken?
Gruß,
Olaf
Olaf Gerecke
"Heinrich Woick" schrieb:
> Olaf Gerecke wrote:
>
> > Gibt es denn hier keinen, der sich wirklich in den Tiefen von Excel-VBA
> > auskennt, und nicht gleich dem Fragenden und Hilfesuchenden unterstellt,
> > einfach zu blöd zu sein?
>
> Es tut mir leid, daß ich diesen Eindruck vermittelt habe. Ich bin von
> der Situation eines einzeln arbeitenden Programmierers ausgegangen, der
> für seine eigenen Fehler mehr oder weniger blind ist, aber beim Erklären
> des Problems gegenüber einem Dritten, der nicht mit der Aufgabenstellung
> vertraut sein muß, plötzlich den Fehler selbst erkennt.
Ja, Heinrich. Ich verstehe, was Du meinst.
Ich bitte um Verzeihung für meine Ungeduld.
> Da der Fehler in deinem kleinen Codebeispiel im Standalone-Test nicht
> auftritt, liegt die Ursache wohl in der Komplexität Deines
> Programmsystems. Und zwar zeitlich vor dem hier zitierten Code. Aber das
> ist natürlich nur Spekulation von mir.
Ja. So weit habe ich auch schon spekuliert.
Allein, mir fehlt jeder Ansatz, wo ich denn noch nach einem möglichen Fehler
suchen könnte.
Gibt es noch irgendwelche konkreten Ideen ?
Dank und Gruß,
Olaf
Bruno Uato
Hallo,
wie Thomas schon geschrieben hat, kann man das geflacker wirungsvoll
unterbinden (siehe auch Eckhardt), wenn auf die ganze Selektiererei
und Aktiviererei verzichtet wird (nur in wenigen Fällen nötig). Also
hier erst einmal die Ursachen beseitigen und nicht die Symptome
kurieren. (Nebenbei: Bei längerer Berechnung dem User einen
Fortschritt melden, sei als Laufbalken oder z.b. das in xl bewußt z.B.
eine Zelle selktiert wird, etc., da der User sehr schnell die Geduld
verliert, wenn sich offensichtlich nichts bewegt)
Das gleiche gilt für EnableEvents, ganz besonders für EnableEvents,
und beides nur im Limmerick, also
Application.enableevents = False
DeineAnweisung
Application.enableevents = true
Da beide die Einstellung bei behalten, sprich steigt dein Code aus,
verzweigt, etc. dann sind die User am A..., da für sie im ersten
Moment die Kiste nicht mehr geht.
Wenn sich um den Schalter, Implementierung ist mir natürlich nicht
bekannt, es sich um Einschalter, Ausschalter, Umschalter handelt, dann
kann meistens ebenfalls drauf verzichtet werden. Im behandelden Event,
das Kriterium abfragen, zb. if Target.Value = "bla" then....
Gerade wenn du in Events auf nicht lokale Variablen (z.B. deine
Schalter) zurückgreifts, können sich unerwartete Nebeneffekte ergeben.
(z.B. gerade die Application.ScreenUpdating und
Application.EnableEvents haben in Events oder eben von dort aufgerufen
Prozeduren (und von dort und von dort und von dort und von dort.....)
nicht verloren. Zudem greifen z.b mehere Addins auf das gleiche Event
zu, dann hast du keine Kontrolle, wann dein Eventbehandelden Sub
ausgeführt wird. Verwendetder andere ähnliche Methoden und schaltet
die Behandlung ein und aus, ohne Limmerick, dann findet sich schon
irgedwo ein Fehler und ...
Du führts in deinem Code z.B. Activecell.offset(0,1).select aus, das
löst z.b. einen Event aus (inden du irgendwas machst, das löst wieder
eine Event aus und das löst..., und.... die Fehlerquelle das mit
hunderten von Schaltern in den griff zu bekommen halte ich, gelinde
gesagt, für kaum durchziehbar.
Mfg, Bruno
Bruno Uato
Hallo,
manche Dinge in xl gefallen mir auch nicht, aber...
1. was ist die bessere Alternative im geschäftlichen Umfeld?
2. keine Software ist fehlerfrei, und je größer und mehr
Anhängigkeiten desto weniger. Und die wenigsten wünschen sich
DOS-Zeiten zurück.
3. Das Stück Code, was du gepostet hat, erschließt sich mir nicht
warum am Anfang gleich die Hammermethoden: Fehler abschalten,
Screenupdating ausschalten, EnableEvents abschalten benutzt werden und
das ohne Not oder ersichtlichen Grund.
4. Der Code geht überhaupt nicht auf die möglicherweise auftretenden
Fehler auf. Da Value von Typ Objekt ist und du davon ausgehst, das
Objekt in jedem Fall in eine Zahl gecastet werden kann, geht dein Code
auf die Bretter, wenn z:b. ein Text in der Zelle steht. Mit den
entsprechend FATALEN Auswirkungen, wegen den Holzhammermethoden zu
beginn der Sub.
5. Meine Empfehlung: Alle Fehlerbehandlungen raus, alle Screenupdating
raus, alle enableevents raus. Auftretenden Fehler etc. sauber
auscodieren und nur im allernötigsten Fall im Limmerik ein- und
ausschalten.
Mfg, Bruno
www.femtooffice.de
Tools for Excel
PS: Eventuell kann dir www.femtooffice.de bei deinem Problemen helfen.
Olaf Gerecke
bitte lies doch erst mal meine Beiträge, bevor Du so ein dummes Zeug
entwortest.
Es hilft doch wirklich nicht weiter, wenn Du hier in aggressiver Weise
völlig an der Sache vorbei argumentierst.
Olaf
"Bruno Uato" schrieb:
Peter KUTTNIG
ich habe großen Respekt vor Deinem so
umfangreichen Projekt und Deinem dadurch
erworbenen Fachwissen.
Bezüglich "ScreenUpdating" musste
ich auch einiges "Lehrgeld" bezahlen
und möchte Dir meine Erkenntnisse
ohne irgendwelche Kommentare mitteilen:
Regel 1:
"ScreenUpdating" gilt global
Ruft eine Prozedur zahlreiche Unterprozeduren auf,
so reicht es "Application.ScreenUpdating=false"
in der Hauptprozedur einmal zu setzen,
man muss es nicht in jeder Unterprozedur auch noch tun.
Regel 2:
Nach dem Beenden der Hauptprozedur setzt
Office_XP "Application.ScreenUpdating" automatisch auf "true"
(Ob das in anderen Versionen auch so ist, weiß ich nicht)
Regel 3:
Zustand von "ScreenUpdating" mittels MsgBox ist
ungleich zum Zustand mittels Intellisense.
Sub Test1()
Application.ScreenUpdating = False
MsgBox Application.ScreenUpdating 'Ergebnis = false
Call Test2
End Sub
Sub Test2()
MsgBox Application.ScreenUpdating 'Ergebnis = false
End Sub
Sub Test3()
MsgBox Application.ScreenUpdating
'Ergebnis = wahr,
'obwohl ScreenUpdating codemäßig nicht verändert wurde
End Sub
Im Einzelschrittmodus F8 liefert Intellisense
(wenn man im Codefenster mit dem Curser über
"ScreenUpdating" fährt) WAHR, während die Msgbox FALSCH liefert.
Es wurde von den Excel-Experten bis jetzt noch nicht geklärt,
ob nur Intellisense damit nicht klar kommt oder ob im
Einzelschrittmodus der Bildschirm zwangsweise aktualisiert wird
und somit die Intellisense-Aussage OK ist, was aber im
Widerspruch zur Realität im Programmablauf steht.
Regel 4:
Prüfe den aktuellen Zustand von "ScreenUpdating"
immer direkt im Code durch Abfrage mit MSGBOX.
Viel Erfolg wünscht Dir
Peter
Bruno Uato
<OlafG...@discussions.microsoft.com> wrote:
>Hallo Bruno,
>
>bitte lies doch erst mal meine Beiträge, bevor Du so ein dummes Zeug
>entwortest.
>Es hilft doch wirklich nicht weiter, wenn Du hier in aggressiver Weise
>völlig an der Sache vorbei argumentierst.
>
>Olaf
Hallo Olaf,
tja was soll ich sagen...wenn dir meine Antwort, zu aggresiv war, so
bedauere ich das, da ich dir nicht auf den Schlips treten
wollte....tja, was das dumme Zeug angeht, überlasse ich dir die
Einschätzung dazu. An dem Stückchen Code, was du gepostet hast, wollte
ich dir die eventuell möglichen Probleme und Seiteneffekt aufzeigen,
was du daraus machst, ist deine Angelegenheit....aber einen
sarkastische, rein rethorische, Frage, kann ich mir dann doch nicht
verkneifen? Gehst du mit deinen Usern, die deine Software benutzen
ebenfalls so um?
Mfg, Bruno
Olaf Gerecke
alles was Du schreibst ist, soweit ich das auch den ersten Blick erkennen
kann, absolut richtig.
Aber es trifft leider auch wieder nicht mein eigentliches Problem.
Ich bedauere inzwischen ScreenUpdating überhaupt erwähnt zu haben, denn die
Hauptprobleme habe ich durch EnableEvents.
Dieser ebenfalls globale Schalter läßt sich in meinem Projekt an den
allermeisten Stellen einfach nicht mehr auf "False" setzen. Es geht in diesem
Fall auch nicht um eine unterschiedliche Anzeige zwischen Intellisense,
Überwachungsfenster oder MsgBox. Alle sagen dasselbe und sämtliche
Event-Routinen werden stur weiterhin ausgeführt, auch wenn ich 27 mal
"Applikation.EnableEvents = False" sage.
Herausgearbeitet haben wir bislang hier nur, dass es möglicherweise an der
Größe meines Projekts liegt, weil das in einer stark abgespeckten XLA nicht
vorkommt, vielleicht aber auch an völlig anderen Bedingungen, von denen wir
nicht wissen, wo wir anfangen sollten, zu suchen. Sollte ersteres der Fall
sein, würde ich gerne wissen. wo die undokumentierten Limitationen liegen, im
zweiten Fall hätte ich gern einen Tipp, wo ich noch suchen kann.
Also: Ungeachtet der Tatsache, dass es selbstverständlich auch in meinem
Code noch jede Menge zu verbessern gibt, was ich sukzessive auch immer mal
wieder tue, wenns die Zeit erlaubt, in diesem Tread geht es nicht um meinen
Code.
Hier geht es nur und ausschließlich um einen inzwischen hinläglich
ausführlich beschriebenen Fehler in Excel-VBA für dessen Umgehung ich auf
eine hilfreiche Antwort bislang vergeblich warte.
Trotzdem Danke,
Olaf
"Peter KUTTNIG" schrieb:
Olaf Gerecke
"Bruno Uato" schrieb:
> ... Gehst du mit deinen Usern, die deine Software benutzen
> ebenfalls so um?
;-)
nur gelegentlich mal, wenn sie mir meine Zeit stehlen, weil sie einfach
nicht lesen, was ich ihnen vorher geschrieben hab. Kommt aber nicht häufig
vor.
Siehe auch meine Antwort an Peter von grade eben.
Mfg, Olaf
Bruno Uato
Alles geschnipp
Hallo Olaf,
manchmal habe ich einfach schlechte Tage, vieleicht ist diese Antwort
besser.
Das war, gekürzt, deine Frage.
>ich verzweifle grade an einem (mir) unerklärlichen Phänomen.
>In einem umfangreichen Excel-VBA-Projekt (Größe der XLA z.Zt. ca. 2,6 MB)
>habe ich - nicht immer, aber leider viel zu oft - den Effekt, dass nach den
>Zeilen
>
> Application.ScreenUpdating = False
> Application.EnableEvents = False
>
>beide Eigenschaften immer noch auf 'True' stehen.
>
>
>Kennt jemand eine mögliche Ursache für dieses Phänomen bzw. einen Kniff, wie
>ich das in den Griff bekomme?
Das ist dein Code:
>Hier mal eine von hunderten Code-Passagen, in denen das Phänomen immer mal
>wieder - aber nicht immer in gleicher Weise - auftritt:
>
>Public Sub Formatieren()
> Dim wsE As Worksheet
> On Local Error Resume Next
> Application.ScreenUpdating = False
> Application.EnableEvents = False
> Set wsE = Workbooks(2).Worksheets(1)
> Select Case wsE.Range("DB_anz_Einheit").value
> Case 1: wsE.Range("Einheit").value = 1
> Case 100: wsE.Range("Einheit").value = 2
> Case 1000: wsE.Range("Einheit").value = 3
> Case Else: wsE.Range("Einheit").value = 4
> End Select
Sehen wir das mal näher an.
>Public Sub Formatieren()
Du rufts eine Prozedur auf, sei per Button, aus einer anderne
Prozedur/Funktion, von einem Ereignis, per run, aus deinem Modul, xla,
Addin, automation-server oder was es sonst noch gibt.
> Dim wsE As Worksheet
Sehe ich kein Problem unter VBA, unter Net eventuell schon
> On Local Error Resume Next
Eine unstrukturierte Fehlerbehandlung, das kann Effekte z.b. in einen
nachfolgenden Aufruf, z,.b in einer deiner Subs haben. Hast du z.B.
deine Sub Formatieren ebenfalls aus z.b. einer Sub aufgerufen die
diese Zeile enthält, dann kann das Auswirkungen auf deine Sub
Formatieren haben, auch wenn diese kein Error Resume enthält. Zudem
erschwert es extrem die Fehlersuche, da weder dir eventuelle Fehler
auffallen oder im schlechteren Fall dem Kunden
> Application.ScreenUpdating = False
Für den weiteren Verlauf deines Makros unnötig. Kommt es im weitern
Verlauf zu einem Fehler, wird der Bildschirm nicht mehr aktualisiert.
> Application.EnableEvents = False
Für den weiteren Verlauf deines Makros unnötig. Dito wie oben, bloss
mit eventuell noch schlimmern Folgen. Stell dir vor ein anderer
Programmier würgt die Events ab, dein Programm will aber ein Event
konsumieren. Du gehst davon aus, das wenn das Event ausgelöst werden
soll, es auch kommt, aber.....dein Programmablauf stimmt hinten und
vorne nicht mehr.
> Set wsE = Workbooks(2).Worksheets(1)
Mögliche Fehlerquelle: Auflistung enthält keinen Eintrag, sprich es
ist kein Mappe geöffnet
Mögliche Fehlerquelle: Auflistung Workbooks enthält weniger Einträge
Mögliche Fehlerquelle: Auflistung Workbooks wurde durch User in der
Reihenfolge verändert
Mögliche Fehlerquelle: Auflistung Workbooks wurde durch Automation in
der Reihenfolge verändert
Mögliche Fehlerquelle: Auflistung Worksheets wurde durch User in der
Reihenfolge verändert
Mögliche Fehlerquelle: Auflistung Worksheets wurde durch Automation in
der Reihenfolge verändert
Mögliche Fehlerquelle Auflistung Worksheets enthält keinen Eintrag ist
nur in dem besonderen Fall ohne Bedeutung
> Select Case wsE.Range("DB_anz_Einheit").value
Möglicher Fehler, das "DB_anz_Einheit" falsch geschrieben wurde, aber
wg. Resume next...
Möglicher Fehler: Name wird durch User geändert
Möglicher Fehler: Name wird durch User gelöscht
Möglicher Fehler: Bezug des Names wird durch User verändert
Möglicher Fehler: Name wird durch Automation verändert
Möglicher Fehler: Name wird durch User gelöscht
Möglicher Fehler: Bezug des Names wird durch Automation verändert
Wenn einer der obigen Bedingungen eintritt oder die unter Workbook
erwähnten, führt der Zugriff auf den benannten Bereich zu einem
Fehler. Was wg. resume next zunächst nicht augenscheinlich wird.
Value ist vom Typ Objekt. Was ist wenn der Eintrag...
einen Text...
einen Textzahl...
einen Logikwert...
ein als Datum zu interpretierenden Wert...
ein als Zeit zu interpretierenden Wert...
ein als Timespan zu interpretierenden Wert..
etc...
enthält.
Zudem gehst du davon aus das der interne Cast des Compilers das
gewünschte Ergebnis liefert, entweder du kennst alle Eventualitäten
aus längstjähriger Erfahrung oder die Implementation, ansonsten ist
das Ergebnis im besten Fall sehr häufig in deinem Sinne.
Versuche mal deinen Code, ohne Zeile 2,3 und 4, füge in deinen
benanten Bereich die Formel = HalloOlaf ein (in der Annahme das du
keine entsprechende UDF etc. hast). Siehe zudem hierzu die Anmerkungen
zu Resume next
> Case 1: wsE.Range("Einheit").value = 1
Wenn, wie unter Workbook erwähnt, dort ein Fehler auftritt ,dann
schlägt diese Anweisung ebnefalls fehl.
Möglicher Fehler: Schreibfehler bei "Einheit" etc., vertippen kann man
sich schnell, fällt zu dem wg.resume next nicht auf.
Was ist wenn der Wert nicht 1 sondern z.B. 1,0000000000000001 ist,
sobald "Einheit" eine Formel enthält oder Wert enthält, der durch eine
Formel, oder allgemeiner gesagt, durch eine ungenaue Operation
entstanden ist (was für fast alles zutrifft) läuft dein Code
bestenfalls in den Case else.
Wenn du solchen Code zu hunderten in deinem Programm laufen hast, dann
hast du eventuell tausende von möglichen Fehlerquellen in deinem Code
und einige unterumständen schwerwiegend oder sogar fatal. Dein Code
enthält, zwar die funktionallen Aspekte, aber es (eventuell
rausgenommen) 20 Prozent Dokumentation und 70% des Codieraufwands für
die Behandlung der Eventualitäten.
Darum empfehle ich dir, wie in einem anderen Posting schon erwähnt:
- Entferne alle unstrukturierten Fehlerbehandlungen
- Entferne alle Screeupdating
- Entferne alle enableEvents
- Codiere deinen Code sauber aus, sprich berücksichtige alle möglichen
Eventualitäten
- Baue ein sauberes Fehlerrückmeldungsystem in deine Applikation ein,
um, a) das du Fehler schneller findest, b) eine brauchbare Rückmeldung
von deinem Kunden bekommen kannst.
- Ursachen beseitigen und nicht Symptome kaschieren.
- Such dir eventuell bezahlte Hilfe, wie. z.b. www.femtooffice.de
Ich hoffe ich bin a) auf deine Frage nach den mögliche Effekten
eingegangen und b) anhand deines Code aufgezeigt.
Mfg, Bruno
Olaf Gerecke
was schafft Dir eigentlich die Befriedigung daran, Dir hier eine solche
Masse zwar intelligenter, aber völlig irrelevanter Hirngespinste zusammen zu
phantasieren.
Du kannst doch anhand dieses winzigen Code-Schnipsels nicht das mindeste
davon beurteilen.
Du weist zum Beispiel nicht, wie die Fehlerbehandlung anschließend durch
Abfragen von Err.Number weitergeht und Du hast nicht die geringste
Vorstellung davon, was vorher schon alles passiert ist. Wenn auch nur eine
einzige der von Dir herbeigesponnenen "möglichen Fehlerquellen" zuträfe, dann
würde das Makro-Projekt gar nicht erst an diesen Punkt gelangen. ...Workbook
oder Worksheet nicht vorhanden... Was für ein Quatsch.
Wir reden hier von einem System, das täglich auf hunderten voin Rechnern
viele Male fehlerfrei ausgeführt wird.
Ein letztes Mal: ES GEHT HIER NICHT UM MEINEN CODE.
Es geht hier nur um den FEHLER VON EXCEL-VBA, dass unter bestimmten
Umständen (evtl in Zusammenhang mit der Größe der XLA, aber das ist noch
nicht sicher) der Schalter "Applikation.EnableEvents" der auf "False" gesetzt
wurde, nach Ausführen der nächsten x-belieibgen Zeile wieder auf "True" steht
und sämtliche Event-Routinen wieder durchlaufen werden, was ich derzeit mit
eigenen Schalter umständlich unterbinden muss.
Das kostet Zeit, Nerven und Performance. Das würde ich gern abstellen.
Und Du kostest auch Zeit und Nerven.
Bitte schreib nicht mehr.
Olaf
"Bruno Uato" schrieb:
Heinrich Woick
> Ein letztes Mal: ES GEHT HIER NICHT UM MEINEN CODE.
>
> Es geht hier nur um den FEHLER VON EXCEL-VBA, dass unter bestimmten
> Umständen ........
... Rest gelöscht
Hallo Olaf,
Dann frag doch Microsoft selbst.
Microsoft Consulting und Supportangebote für Geschäftskunden, sind
sicher auch nicht dumm und warten schon auf Arbeit mit Microsoft Produkten.
Heinrich
Olaf Gerecke
genau das habe ich schon vor zwei Monaten getan. Außer der sofortigen
automatischen Zuteilung einer Case-Nummer ist seitdem nichts passiert.
Nein. die "warten" nicht auf Arbeit. Die Kunden warten auf Antwort.
Und zwar vergeblcih!
Dank & Gruß,
Olaf
"Heinrich Woick" schrieb:
> Olaf Gerecke wrote:
>
> > Ein letztes Mal: ES GEHT HIER NICHT UM MEINEN CODE.
> >
> > Es geht hier nur um den FEHLER VON EXCEL-VBA, dass unter bestimmten
> > Umständen ........
> .... Rest gelöscht
Olaf Gerecke
entschuldige bitte - so Du kannst - meinen leider wieder etwas gereizten
Tonfall in meiner letzten Antwort an Dich.
Ich bin leider wirklich etwas überreizt und überarbeitet. Seit nunmehr 16
Monaten arbeite ich rund um die Uhr (jeden Tag, jede Nacht, jedes Wochenende
und jeden Feiertag) um ein Projekt zu retten, dass bei genauem Hinsehen
eigentlich längst nicht mehr zu retten ist. (und m.E. ist der ganze Ansatz
"Schriftverkehr via Excel" ziemlicher Unfug,... aber das wurde "vor meiner
Zeit" entschieden.)
Ich möchte das jetzt nicht näher ausführen. Das würde viele Stunden
brauchen und kein Mensch hätte Lust, all das zu lesen... was ich sehr gut
verstehen kann...
Meine Hoffnung war, dass die hier in diesem Forum aktiven Mitarbeiter von
Microsoft mit ihrem vielleicht etwas "näheren Draht" zur Company, vielleicht
etwas in Gang setzten könnten, was mir als recht kleinem und unbedeutendem
Kunden nicht gelingt.
Ich denke inzwischen, das Experiment ist gescheitert.
Die MS-Kollegen haben sich schon seit Tagen nicht mehr gemeldet.
Also muss ich trotz aller Excel-Fehler sehen, wie ich mich irgendwie
durchschlage.
Dir wollte ich nur sagen:
Dich wollte ich mit meiner Greiztheit nicht treffen. Du kannst nichts dafür.
Lieben Dank und freundliche Grüße,
Olaf
Heinrich Woick
> entschuldige bitte - so Du kannst - meinen leider wieder etwas
gereizten
> Tonfall in meiner letzten Antwort an Dich.
> Die MS-Kollegen haben sich schon seit Tagen nicht mehr gemeldet.
> Also muss ich trotz aller Excel-Fehler sehen, wie ich mich irgendwie
> durchschlage.
> Dir wollte ich nur sagen:
> Dich wollte ich mit meiner Greiztheit nicht treffen. Du kannst nichts dafür.
> Lieben Dank und freundliche Grüße,
Hallo Olaf,
Danke, aber das ist jetzt unverdiente Ehre am falschen Objekt.
Für Deine Gereiztheit kann niemand etwas, außer Dir selbst. Den Dank
haben diejenigen verdient, die Dich zentnerweise mit guten und
konstruktiven Vorschlägen und Hinweisen zur Fehlersuche überhäuft haben.
Denn anders als mit ausführlichen Tests kommst Du nicht weiter, egal ob
der Fehler nun auf Microsoft oder Deine Vorgänger zurückgeht.
Mir scheint, das Thema ist damit ausgereizt, jedenfalls wünsche ich
Euch, daß Ihr das Problem noch in den Griff kriegt.
Heinrich