Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf

de-users
#1

Hallo,

ich habe hier in einer ZIP-Datei (Musterdatei.zip) zwei Dateien hochgeladen.
https://c.web.de/@693152299987503749/c_8KMmxvSECrDWBwx8_83Q

a) Die Writerdatei enthält das Makro, welches über eine Schaltfläche
gestartet werden kann.
b) Die Calcdatei enthält Texte, welche vom Makro in ein Array eingelesen
werden.
c) Nach dem Lesen werden diese Text, entsprechend des Musters in der
Calcdatei,
in das Writerdokuemnt geschrieben/ verteilt.

Das Makro läuft fehlerfrei durch, d.h. es werden alle Texte verteilt und
nach Abschluß erscheint eine Messagebox, mit dem Hinweis,
dass alle Texte geschrieben wurden.
Genau in diesem Augenblick friert LibreOffice ein.
Man kann LibreOffice nur über den Taskmanager abschießen.

a) In allen LibreOffice-Versionen VOR 6.2.1.2, funktioniert das Makro
einwandfrei.
b) In AOO 4.1.6 funktioniert das Makro einwandfrei
c) Mit LibreOffice-Version 6.3 (Master vom 28.03.2019)*) friert
LibreOffice ein.
*)
Version: 6.3.0.0.alpha0+ (x64)
Build ID: ed6a71eafa61bade50219d2ff6233a42ab6d1c17
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win;
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-28_01:15:23
Locale: de-DE (de_DE); UI-Language: en-US
Calc: CL

Da das Makro in den LO-Vorgängerversionen funktioniert und
in AOO 4.1.6 heute noch funktioniert, bezweifele ich eigentlich,
das die Problem an einem Programmierfehler liegt. Es sei denn
die LO-Vorgängerversionen und AOO sind fehlertoleranter.
Deshalb bitte ich jemanden mein Makro zu testen und mir ggf. eine Lösung
anzubieten.
Hinweis:
Der Absturz, bzw. das Einfrieren erfolgt in der Sub-Routine "Sub Seite",
direkt vor "END SUB" an Position:
    MsgBox("Die Kopfzeileninhalte wurden ab Seite 2 bis zur Seite "...
Die Messagebox wird noch angezeigt, aber es ist nicht möglich den
OK-Button zu betätigen.

Viele Grüße

Jürgen

#2

Hallo Jürgen,

...
ich habe hier in einer ZIP-Datei (Musterdatei.zip) zwei Dateien hochgeladen.
https://c.web.de/@693152299987503749/c_8KMmxvSECrDWBwx8_83Q

in der heruntergeladenen zip-Datei ist bei mir lediglich einen Calc-Datei drin - und die besitzt keine Makros.

Kann also wenig zu sagen....

Viele Grüße

Thomas

#3

Hallo Thomas,

sorry, so passiert es wenn man nicht alles überprüft.
Der vorherige Link funktioniert jetzt, bzw. in der ZIP sind beide
Dateien enthalten.

Viele Grüße

Jürgen

#4

Hallo Thomas,

habe nun meinen Code entsprechend Deines Ratschlags und diverser anderer
Ungereimtheiten überarbeitet.

Musterdateien_02.zip
steht hier zum Download bereit:
https://c.web.de/@693152299987503749/RJCw-SFyQFK1cq8oL0FtFA

Das Programm läuft jetzt unter diesen OfficeVersionen:
a)  LO 6.1.4.2 Portable
b)  LO 6.2.1.2
c)  LO 6.3.0.0.alpha0+ (x64)
d) AOO 4.1.6 --> rasend schnell

ABER:
Sobald ich im Code unter LibreOffice (egal welche Version) die
abschließende Messagebox aktiviere, friert LO ein.
Unter OpenOffice funktioniert die Ausführung auch mit der letzten
Messagebox. Zu dem mit rasantem Tempo.

Die Passagen an denen ich die MsgBox platziert habe und wo diese zum
Einfrieren führen, habe ich wie folgt gekennzeichnet:
REM ???
…

Ich bitte Dich den Code nochmals zu analysieren und mir einen Tipp zu geben.

Vielen Dank und Grüße

Jürgen

#5

Hallo Jürgen,

bevor ich dir eine wahrscheinliche Erklärung liefere, möchte ich eine leise Kritik loswerden: so ein kompliziertes Programm zu liefern mit der Aussage, dass jetzt eine Msgbox nicht funktioniert, ist ein bisschen wenig. Als erstes solltest du versuchen, das Problem einzugrenzen, das Programm zu reduzieren auf möglichst einfache und kurze Codes, damit es für jemand anderen leichter nachvollziehbar ist. Das erhöht auch die Chance, dass jemand dran bleibt und den Grund findet und nicht die Lust verliert.
Ich denke, in meinem Fall bin ich glücklicherweise schnell auf etwas gestoßen: Ich habe mir - ein Reduktionsfaktor - nur die Routine btnStart.. angeschaut. Bei xSeite mit der anschließenden Msgbox habe ich nichts Auffälliges gesehen, daher habe ich die davor liegende Routine DateiDialog ins Visier genommen, da war auch nichts offensichtlich Verdächtiges, also weiter zu FileOperation. Da habe ich Xray oDocC eingefügt; du hast ja mri drin, aber das scheint ja irgendwie eingefroren zu sein, hanya hat erklärt, dass er das nicht mehr weiter betreibt; aber Xray würde ja im Grunde das gleiche liefern.
Nun blieb aber auch Xray hängen; übrigens ist dann wie auch beim ursprünglichen Fall LibO aktiv, der TaskManager zeigt 27 - 30 % an.
So war das nun schon ziemlich eingeschränkt, das Öffnen des Calc-Dokuments, das in dieser Routine geschieht, ist wohl irgendwie problematisch. Vorher war mir schon aufgefallen, dass die Dimensionierung von FileProperties mit 1 falsch war, weil du nur ...(0) zuweist, aber das hatte keinen Einfluss. Das solltest du zwar ändern, aber das ist eher Kosmetik (technisch gesehen), aber sinnvoll (für das Verständnis).
Aber der Grund für das Problem scheint zu sein, dass der Name FileProperties natürlich verdächtig ist. Wenn ich den bei allen Vorkommen in dieser Routine ändere, durch einen vorangestellten Buchstaben z. B., dann friert LibO bei mir nicht mehr ein, das Programm läuft durch.
Man kann wohl daraus schließen, dass jetzt irgendwo eine Abfrage auf den String "FileProperties" erfolgt, der ja auch irgendwie nach systemimmanent riecht, die irgend etwas bewirkt, das in unserem Kontext schädlich ist. Die Wahl "FileProperties" ist ja nicht wirklich falsch, obwohl es strenggenommen keine Eigenschaften der Datei selbst sind, die du in diesem Fall angibst, sondern speziell für das Öffnen in diesem konkreten Fall verwendete Parameter. Aber du solltest hier eine andere Variablenbenennung verwenden, weil offensichtlich "FileProperties" schon belegt ist.
Ich hoffe, dass damit dein Problem auch in der Originaldatei gelöst ist.

Gruß

Gerhard

#6

Hallo Jürgen,

Hallo Thomas,

habe nun meinen Code entsprechend Deines Ratschlags und diverser anderer
Ungereimtheiten überarbeitet.

Schon mal gut :slight_smile:

Könntest aber noch ein paar andere "Kleinigkeiten" bereinigen:

Keine Variable als "global" definieren!!!! "Global"-Variable werden im Arbeitsspeicher aktiv gehalten, auch wen Dein (Makro-) Programm bereits beendet ist. Jedes andere Programm oder Modul kann darauf zugreifen und diese auslesen oder verändern. Ist eine Sicherheitslücke und ganz schlechter Programmierstiel (es sei denn, es ist tatsächlich notwendig). Du brauchst keine Global-Variablen! In Deinem Fall würde DIM immer ausreichen, falls Du mehrere Module betreibst und kein Windows benutzt, wäre "Privat" die korrekte Definition.

Die "Call" Aufrufe kannst Du Dir ersparen. Ist in VBA nötig, nicht aber in LO/AOO Basic. Hier reicht es völlig, den Funktionsnamen zu verwenden. "CAll" errinnert zu sehr an VBA und ist nur der Kompatibilität mit im Funktionsumfang.

Zu den Variablen-Namen hat Gerhard schon was gesagt. Es gibt einfach Namen, die werden auch vom Programm intern verwendet - wenn Du diese dann noch als "globale" Variablen festlegst, ist Chaos vorprogrammiert. Leider gibt es keine Liste interner Variablen-Namen. Hier ist einfach etwas Phantasie gefragt: je eindeutiger eigene Namen sind um so unverdächtiger. HIer gilt es: experimentieren.

Wenn das Programm bei der msgbox abschmiert (wie Du selbst scheibst und wahrscheinlich nach vielen Versuchen identifiziert hast?) würde ich mal mit einer Pause vor der msgbox arbeiten. Manchmal "überholen" sich interne Prozesse - sie sind dann einfach zu schnell. Ergebnis: Absturz. Oft hilft dann einfach eine wait() Funktion vor dem Absturzprozess - bei Dir also vor der Msgbox. Starte mit "Wait(500)" - und reduziere den später auf den kleinst möglichen Wert. Ein Wait(100) ist meist kaum zu spüren vom Anwender.

Einen "echten" Fehler konnte ich jetzt nicht entdecken im Code - hab aber auch nicht intensiv gesucht;)

Viele Grüße

Thomas