Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo,
hier ist meine neueste Programmversion downloadbar:
https://c.web.de/@693152299987503749/TEUWlWI8QO-qH48WLyv5Vw
@Hans-Werner
Ich habe mir Deinen sehr interessanten Code angesehen und ausprobiert.
Erst war ich von Deinem Programmierstil etwas verwirrt.
Meine kleinen grauen Zellen konnten aber alles entschlüsseln.
Deine Schleife zum Schreiben und Löschen der Texte ist sehr interessant.
Da aber ggf. noch einige Erweiterungen für mein Programm anstehen, kann
ich diesen Schleifenaufbau so nicht nutzen. Für Schreiben und Löschen
brauche ich für zukünftige Erweiterungen zwei getrennte Routinen.
Besonders schön finde ich die Hilfe.
Den Textaufbau habe ich gleich in meine neue Version eingebaut.
@Alle
Meine Kommentare im Code sind u.U. nicht immer professionell,
aber hoffentlich ausreichend verständlich.
Bin halt nur ein Autodidakt und sonstige Kritik nehme ich auch gerne
entgegen.
Man lernt halt nie aus :-)
Im Dokument habe ich zu meinem Hauptprogramm noch ein Modul
mit dem Namen "xBackUp" abgespeichert. Dieses soll ein kleines Dankeschön
für Eure vielfältige Hilfe und Arbeit sein. Vielleicht habt Ihr Euch
selbst schon so etwas
programmiert, wenn nicht wünsche ich Euch viel Erfolg damit.
Weitere Informationen stehen in den Code-Kommentaren.
Viele Grüße
Jürgen
Am 09.04.2019 um 20:54 schrieb Jürgen Klatt:
Hallo,
Info Bugreport Libo friert ein bei Button-Event "Aktion bestätigen":
https://bugs.documentfoundation.org/show_bug.cgi?id=124628
Viele Grüße
Jürgen
Am 09.04.2019 um 01:19 schrieb OoOHWHOoO:
Hallo Gerhard,
das mit dem "Aufruf über das Dokumentereignis" war (m)eine Notlösung.
Ich habe mich genau an Deine Anweisungen gehalten, hat auch alles
geklappt, aber nur eines nicht: Dass der Dialog mit der Schaltfläche
im WRITER-Dokument erscheint. Im Moment weiß ich noch nicht, was ich
falsch mache:
"[...] bis "Module1" erscheint, das anklicken -> rechts
"btnStart_actionPerformed" anklicken. Dann OK und nochmal OK und
speichern (das speichert den Dialog im Dokument und auch das Dokument
selbst im Dateisystem). [...]".
Mein Problem ist, dass ich das zweite "OK" nicht finde - daran wird es
wohl liegen ...
Grüße
Hans-Werner
-- Originalnachricht --
Von: "Gerhard Weydt"
An: users@de.libreoffice.org
Gesendet: 08.04.2019 22:29:05
Betreff: Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice
nach Makrodurchlauf
Hallo Hans-Werner,
wenn du die Bedingungen änderst, testest du aber etwas anderes! Schon
nur "zusätzlich" müsste man genau anschauen, aber du hast
"stattdessen" gemacht":
Gerade an der kniffligen Stelle, wo wir schon wissen, dass es mit dem
direkten Aufruf des Makro geht, aber nicht mit dessen Aufruf per
Schaltfläche, hast du eine dritte Variante getestet. Das ist ja nun
nicht per se falsch, man muss sich halt nur im Klaren sein, dass es
etwas anderes ist.
Dass deine Variante durchläuft, sagt ja jetzt nichts über meinen
Fall: ich habe bei deiner Datei die Schaltfläche ergänzt und den
Aufruf dorthin gelegt, und schon bleibt LibO wieder stecken. Der
Aufruf über das Dokumentereignis ist entweder dem direkten Aufruf
ähnlicher, oder das Problem hängt nicht prinzipiell am Aufruf von
einer Schaltfläche aus, sondern vielleicht, wie Jürgen wohl getestet
hat, speziell am Ereignis "Aktion auslösen" (was es ja auch beim
Dokument logischerweise nicht gibt).
Und zweitens hast du _gleichzeitig_ eine zweite Änderung gemacht, was
auch nicht zu empfehlen ist, wenn man ein Problem lokalisieren will.
Die Idee mit einer leeren Datei ist mir gestern beim Einschlafen auch
gekommen, weil mich die zweite Datei gestört hat, man kann das so
schlecht als Beispiel zur Verfügung stellen. Schön, dass du das schon
probiert hast, ich habe es nachvollzogen, in diesem Fall sind die
Reaktionen offenbar identisch, ob es nun eine bestehende oder neue
Datei ist.
Jetzt warte ich mal auf Jürgens Bug-Report und die Reaktion darauf.
Viele Grüße
Gerhard
Am 08.04.2019 um 09:10 schrieb OoOHWHOoO:
Guten Morgen Gerhard,
erst mal ganz herzlichen Dank für Dein ausführliches
Dialog-Anlegen-Tutorial :-)) !!!
Das habe ich, denke ich mal, hinbekommen.
Zusätzlich habe ich noch 2 Dinge gemacht:
[1] Via [Extras] > [Anpassen "Ereignisse"] > [Dokument öffnen] >
[Makro]: Dokument öffnen * Standard.Module.StartKopfzeile] das
Dokument so "eingestellt", dass beim Öffnen direkt der Dialog mit
der Schaltfläche "CommandButton1" angezeigt wird.
[2] In "Sub btnStart_actionPerformed(oEvent2)" wird eine neue
CALC-Datei geöffnet. Sollte eigentlich keinen Unterschied machen, ob
man eine bestehende oder eine neue CALC-Datei öffnet.
Dein von mir modifiziertes Makro schaut nun so aus:
Option Explicit
Sub StartKopfzeile
Dim oDlg as Object
DialogLibraries.LoadLibrary("Standard")
oDlg = createUnoDialog(DialogLibraries.Standard.Dialog1)
oDlg.execute
End Sub
Su
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo,
Info Bugreport Libo friert ein bei Button-Event "Aktion bestätigen":
https://bugs.documentfoundation.org/show_bug.cgi?id=124628
Viele Grüße
Jürgen
Am 09.04.2019 um 01:19 schrieb OoOHWHOoO:
Hallo Gerhard,
das mit dem "Aufruf über das Dokumentereignis" war (m)eine Notlösung.
Ich habe mich genau an Deine Anweisungen gehalten, hat auch alles
geklappt, aber nur eines nicht: Dass der Dialog mit der Schaltfläche
im WRITER-Dokument erscheint. Im Moment weiß ich noch nicht, was ich
falsch mache:
"[...] bis "Module1" erscheint, das anklicken -> rechts
"btnStart_actionPerformed" anklicken. Dann OK und nochmal OK und
speichern (das speichert den Dialog im Dokument und auch das Dokument
selbst im Dateisystem). [...]".
Mein Problem ist, dass ich das zweite "OK" nicht finde - daran wird es
wohl liegen ...
Grüße
Hans-Werner
-- Originalnachricht --
Von: "Gerhard Weydt"
An: users@de.libreoffice.org
Gesendet: 08.04.2019 22:29:05
Betreff: Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice
nach Makrodurchlauf
Hallo Hans-Werner,
wenn du die Bedingungen änderst, testest du aber etwas anderes! Schon
nur "zusätzlich" müsste man genau anschauen, aber du hast
"stattdessen" gemacht":
Gerade an der kniffligen Stelle, wo wir schon wissen, dass es mit dem
direkten Aufruf des Makro geht, aber nicht mit dessen Aufruf per
Schaltfläche, hast du eine dritte Variante getestet. Das ist ja nun
nicht per se falsch, man muss sich halt nur im Klaren sein, dass es
etwas anderes ist.
Dass deine Variante durchläuft, sagt ja jetzt nichts über meinen
Fall: ich habe bei deiner Datei die Schaltfläche ergänzt und den
Aufruf dorthin gelegt, und schon bleibt LibO wieder stecken. Der
Aufruf über das Dokumentereignis ist entweder dem direkten Aufruf
ähnlicher, oder das Problem hängt nicht prinzipiell am Aufruf von
einer Schaltfläche aus, sondern vielleicht, wie Jürgen wohl getestet
hat, speziell am Ereignis "Aktion auslösen" (was es ja auch beim
Dokument logischerweise nicht gibt).
Und zweitens hast du _gleichzeitig_ eine zweite Änderung gemacht, was
auch nicht zu empfehlen ist, wenn man ein Problem lokalisieren will.
Die Idee mit einer leeren Datei ist mir gestern beim Einschlafen auch
gekommen, weil mich die zweite Datei gestört hat, man kann das so
schlecht als Beispiel zur Verfügung stellen. Schön, dass du das schon
probiert hast, ich habe es nachvollzogen, in diesem Fall sind die
Reaktionen offenbar identisch, ob es nun eine bestehende oder neue
Datei ist.
Jetzt warte ich mal auf Jürgens Bug-Report und die Reaktion darauf.
Viele Grüße
Gerhard
Am 08.04.2019 um 09:10 schrieb OoOHWHOoO:
Guten Morgen Gerhard,
erst mal ganz herzlichen Dank für Dein ausführliches
Dialog-Anlegen-Tutorial :-)) !!!
Das habe ich, denke ich mal, hinbekommen.
Zusätzlich habe ich noch 2 Dinge gemacht:
[1] Via [Extras] > [Anpassen "Ereignisse"] > [Dokument öffnen] >
[Makro]: Dokument öffnen * Standard.Module.StartKopfzeile] das
Dokument so "eingestellt", dass beim Öffnen direkt der Dialog mit
der Schaltfläche "CommandButton1" angezeigt wird.
[2] In "Sub btnStart_actionPerformed(oEvent2)" wird eine neue
CALC-Datei geöffnet. Sollte eigentlich keinen Unterschied machen, ob
man eine bestehende oder eine neue CALC-Datei öffnet.
Dein von mir modifiziertes Makro schaut nun so aus:
Option Explicit
Sub StartKopfzeile
Dim oDlg as Object
DialogLibraries.LoadLibrary("Standard")
oDlg = createUnoDialog(DialogLibraries.Standard.Dialog1)
oDlg.execute
End Sub
Sub btnStart_actionPerformed(oEvent2)
Dim PV() As New com.sun.star.beans.PropertyValue
StarDesktop.loadComponentFromURL("private:factory/scalc",
"_blank",0,PV())
MsgBox("Last line of ""Sub btnStart_actionPerformed"" ...")
End Sub
Ich hoffe, das geht so in Ordnung, und ich habe nichts
"verschlimmbessert" durch meine (Mini-) Modifikationen Deines Makros
oder etwas entfernt, wodurch Deine Test-Ergebnisse verändert würden.
Test-Ergebnis: Läuft wir geschmiert (LO 6.2.2.2 (x64) @ Windows 7
Home Premium 64-bit) - auch wenn ich den PC neu gestartet habe.
Aber ich kann ja viel behaupten, deshalb hier der DownloadLink von
"TestDialog.odt": https://www.magentacloud.de/share/npm0d3-mxx
Viele Grüße
Hans-Werner
-- Originalnachricht --
Von: "Gerhard Weydt"
An: users@de.libreoffice.org
Gesendet: 07.04.2019 23:45:05
Betreff: Re: [de-users] Versionsabhängiges Einfrieren von
LibreOffice nach Makrodurchlauf
Hallo Hans-Werner,
deine Mail hattee ich heute früh noch gelesen, mir war klar, dass
hinter dem Syntaxfehler etwas anderes stecken müsse, das ist in x
Tests bei mir durchgelaufen und stammt auch aus Jürgens Code (bis
auf die Änderung von global zu dim, die schon Thomas angesprochen
hat).
Der Dialog muss natürlich in jürgens Code fehlen, er hat
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Gerhard,
das mit dem "Aufruf über das Dokumentereignis" war (m)eine Notlösung.
Ich habe mich genau an Deine Anweisungen gehalten, hat auch alles
geklappt, aber nur eines nicht: Dass der Dialog mit der Schaltfläche im
WRITER-Dokument erscheint. Im Moment weiß ich noch nicht, was ich falsch
mache:
"[...] bis "Module1" erscheint, das anklicken -> rechts
"btnStart_actionPerformed" anklicken. Dann OK und nochmal OK und
speichern (das speichert den Dialog im Dokument und auch das Dokument
selbst im Dateisystem). [...]".
Mein Problem ist, dass ich das zweite "OK" nicht finde - daran wird es
wohl liegen ...
Grüße
Hans-Werner
-- Originalnachricht --
Von: "Gerhard Weydt"
An: users@de.libreoffice.org
Gesendet: 08.04.2019 22:29:05
Betreff: Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice
nach Makrodurchlauf
Hallo Hans-Werner,
wenn du die Bedingungen änderst, testest du aber etwas anderes! Schon nur "zusätzlich" müsste
man genau anschauen, aber du hast "stattdessen" gemacht":
Gerade an der kniffligen Stelle, wo wir schon wissen, dass es mit dem direkten
Aufruf des Makro geht, aber nicht mit dessen Aufruf per Schaltfläche, hast du
eine dritte Variante getestet. Das ist ja nun nicht per se falsch, man muss
sich halt nur im Klaren sein, dass es etwas anderes ist.
Dass deine Variante durchläuft, sagt ja jetzt nichts über meinen Fall: ich habe bei
deiner Datei die Schaltfläche ergänzt und den Aufruf dorthin gelegt, und schon bleibt
LibO wieder stecken. Der Aufruf über das Dokumentereignis ist entweder dem direkten
Aufruf ähnlicher, oder das Problem hängt nicht prinzipiell am Aufruf von einer
Schaltfläche aus, sondern vielleicht, wie Jürgen wohl getestet hat, speziell am Ereignis
"Aktion auslösen" (was es ja auch beim Dokument logischerweise nicht gibt).
Und zweitens hast du _gleichzeitig_ eine zweite Änderung gemacht, was auch
nicht zu empfehlen ist, wenn man ein Problem lokalisieren will. Die Idee mit
einer leeren Datei ist mir gestern beim Einschlafen auch gekommen, weil mich
die zweite Datei gestört hat, man kann das so schlecht als Beispiel zur
Verfügung stellen. Schön, dass du das schon probiert hast, ich habe es
nachvollzogen, in diesem Fall sind die Reaktionen offenbar identisch, ob es nun
eine bestehende oder neue Datei ist.
Jetzt warte ich mal auf Jürgens Bug-Report und die Reaktion darauf.
Viele Grüße
Gerhard
Am 08.04.2019 um 09:10 schrieb OoOHWHOoO:
Guten Morgen Gerhard,
erst mal ganz herzlichen Dank für Dein ausführliches Dialog-Anlegen-Tutorial
:-)) !!!
Das habe ich, denke ich mal, hinbekommen.
Zusätzlich habe ich noch 2 Dinge gemacht:
[1] Via [Extras] > [Anpassen "Ereignisse"] > [Dokument öffnen] > [Makro]: Dokument öffnen *
Standard.Module.StartKopfzeile] das Dokument so "eingestellt", dass beim Öffnen direkt der Dialog mit der
Schaltfläche "CommandButton1" angezeigt wird.
[2] In "Sub btnStart_actionPerformed(oEvent2)" wird eine neue CALC-Datei
geöffnet. Sollte eigentlich keinen Unterschied machen, ob man eine bestehende oder eine
neue CALC-Datei öffnet.
Dein von mir modifiziertes Makro schaut nun so aus:
Option Explicit
Sub StartKopfzeile
Dim oDlg as Object
DialogLibraries.LoadLibrary("Standard")
oDlg = createUnoDialog(DialogLibraries.Standard.Dialog1)
oDlg.execute
End Sub
Sub btnStart_actionPerformed(oEvent2)
Dim PV() As New com.sun.star.beans.PropertyValue
StarDesktop.loadComponentFromURL("private:factory/scalc", "_blank",0,PV())
MsgBox("Last line of ""Sub btnStart_actionPerformed"" ...")
End Sub
Ich hoffe, das geht so in Ordnung, und ich habe nichts "verschlimmbessert"
durch meine (Mini-) Modifikationen Deines Makros oder etwas entfernt, wodurch Deine
Test-Ergebnisse verändert würden.
Test-Ergebnis: Läuft wir geschmiert (LO 6.2.2.2 (x64) @ Windows 7 Home Premium
64-bit) - auch wenn ich den PC neu gestartet habe.
Aber ich kann ja viel behaupten, deshalb hier der DownloadLink von
"TestDialog.odt": https://www.magentacloud.de/share/npm0d3-mxx
Viele Grüße
Hans-Werner
-- Originalnachricht --
Von: "Gerhard Weydt"
An: users@de.libreoffice.org
Gesendet: 07.04.2019 23:45:05
Betreff: Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach
Makrodurchlauf
Hallo Hans-Werner,
deine Mail hattee ich heute früh noch gelesen, mir war klar, dass hinter dem
Syntaxfehler etwas anderes stecken müsse, das ist in x Tests bei mir
durchgelaufen und stammt auch aus Jürgens Code (bis auf die Änderung von global
zu dim, die schon Thomas angesprochen hat).
Der Dialog muss natürlich in jürgens Code fehlen, er hat ja den Dialog mit
vielen Statements selbst generiert und musste zusätzlich Listener für seine
Schaltflächen definieren und diese abfragen. Dafür gibt es manchmal Gr
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Hans-Werner,
wenn du die Bedingungen änderst, testest du aber etwas anderes! Schon
nur "zusätzlich" müsste man genau anschauen, aber du hast "stattdessen"
gemacht":
Gerade an der kniffligen Stelle, wo wir schon wissen, dass es mit dem
direkten Aufruf des Makro geht, aber nicht mit dessen Aufruf per
Schaltfläche, hast du eine dritte Variante getestet. Das ist ja nun
nicht per se falsch, man muss sich halt nur im Klaren sein, dass es
etwas anderes ist.
Dass deine Variante durchläuft, sagt ja jetzt nichts über meinen Fall:
ich habe bei deiner Datei die Schaltfläche ergänzt und den Aufruf
dorthin gelegt, und schon bleibt LibO wieder stecken. Der Aufruf über
das Dokumentereignis ist entweder dem direkten Aufruf ähnlicher, oder
das Problem hängt nicht prinzipiell am Aufruf von einer Schaltfläche
aus, sondern vielleicht, wie Jürgen wohl getestet hat, speziell am
Ereignis "Aktion auslösen" (was es ja auch beim Dokument logischerweise
nicht gibt).
Und zweitens hast du _gleichzeitig_ eine zweite Änderung gemacht, was
auch nicht zu empfehlen ist, wenn man ein Problem lokalisieren will. Die
Idee mit einer leeren Datei ist mir gestern beim Einschlafen auch
gekommen, weil mich die zweite Datei gestört hat, man kann das so
schlecht als Beispiel zur Verfügung stellen. Schön, dass du das schon
probiert hast, ich habe es nachvollzogen, in diesem Fall sind die
Reaktionen offenbar identisch, ob es nun eine bestehende oder neue Datei
ist.
Jetzt warte ich mal auf Jürgens Bug-Report und die Reaktion darauf.
Viele Grüße
Gerhard
Am 08.04.2019 um 09:10 schrieb OoOHWHOoO:
Guten Morgen Gerhard,
erst mal ganz herzlichen Dank für Dein ausführliches
Dialog-Anlegen-Tutorial :-)) !!!
Das habe ich, denke ich mal, hinbekommen.
Zusätzlich habe ich noch 2 Dinge gemacht:
[1] Via [Extras] > [Anpassen "Ereignisse"] > [Dokument öffnen] >
[Makro]: Dokument öffnen * Standard.Module.StartKopfzeile] das
Dokument so "eingestellt", dass beim Öffnen direkt der Dialog mit der
Schaltfläche "CommandButton1" angezeigt wird.
[2] In "Sub btnStart_actionPerformed(oEvent2)" wird eine neue
CALC-Datei geöffnet. Sollte eigentlich keinen Unterschied machen, ob
man eine bestehende oder eine neue CALC-Datei öffnet.
Dein von mir modifiziertes Makro schaut nun so aus:
Option Explicit
Sub StartKopfzeile
Dim oDlg as Object
DialogLibraries.LoadLibrary("Standard")
oDlg = createUnoDialog(DialogLibraries.Standard.Dialog1)
oDlg.execute
End Sub
Sub btnStart_actionPerformed(oEvent2)
Dim PV() As New com.sun.star.beans.PropertyValue
StarDesktop.loadComponentFromURL("private:factory/scalc",
"_blank",0,PV())
MsgBox("Last line of ""Sub btnStart_actionPerformed"" ...")
End Sub
Ich hoffe, das geht so in Ordnung, und ich habe nichts
"verschlimmbessert" durch meine (Mini-) Modifikationen Deines Makros
oder etwas entfernt, wodurch Deine Test-Ergebnisse verändert würden.
Test-Ergebnis: Läuft wir geschmiert (LO 6.2.2.2 (x64) @ Windows 7 Home
Premium 64-bit) - auch wenn ich den PC neu gestartet habe.
Aber ich kann ja viel behaupten, deshalb hier der DownloadLink von
"TestDialog.odt": https://www.magentacloud.de/share/npm0d3-mxx
Viele Grüße
Hans-Werner
------ Originalnachricht --
Von: "Gerhard Weydt"
An: users@de.libreoffice.org
Gesendet: 07.04.2019 23:45:05
Betreff: Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice
nach Makrodurchlauf
Hallo Hans-Werner,
deine Mail hattee ich heute früh noch gelesen, mir war klar, dass
hinter dem Syntaxfehler etwas anderes stecken müsse, das ist in x
Tests bei mir durchgelaufen und stammt auch aus Jürgens Code (bis auf
die Änderung von global zu dim, die schon Thomas angesprochen hat).
Der Dialog muss natürlich in jürgens Code fehlen, er hat ja den
Dialog mit vielen Statements selbst generiert und musste zusätzlich
Listener für seine Schaltflächen definieren und diese abfragen. Dafür
gibt es manchmal Gründe, und auch er scheint einen triftigen Grund
gehabt zu haben, aber meist ist es bequemer, den Dialog in der
Basic-IDE zu designen und im Dokument zu speichern. Die Listener
werden sicher auch dann gebraucht, bloß übernimmt das dann
LibreOffice im Hintergrund, man muss nur bei Dialog beim gewünschten
Ereignis das auszuführende Makro benennen.
Für unseren Zweck war mir ein möglichst kurzer Code wichtig, damit
ein Entwickler nicht abgeschreckt wird.
Und ein Rückgriff auf Jürgens Dokument ist auch nicht notwendig, der
Fehler tritt auch bei einem leeren Dokument auf, und auch, wenn man
ein anderes LibO-Dokument statt seines Calc-Dokuments lädt.
Da mir daran liegt, dass jemand anders das auch mit meinem Beispiel
bestätigt, bevor ich eine Bugmeldung aufmache, beschreibe ich dir die
nötigen Aktionen, es geht ziemlich schnell, das sieht nur in der
Beschreibung so groß aus.
Erzeuge ei
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Guten Morgen Gerhard,
erst mal ganz herzlichen Dank für Dein ausführliches
Dialog-Anlegen-Tutorial :-)) !!!
Das habe ich, denke ich mal, hinbekommen.
Zusätzlich habe ich noch 2 Dinge gemacht:
[1] Via [Extras] > [Anpassen "Ereignisse"] > [Dokument öffnen] >
[Makro]: Dokument öffnen * Standard.Module.StartKopfzeile] das Dokument
so "eingestellt", dass beim Öffnen direkt der Dialog mit der
Schaltfläche "CommandButton1" angezeigt wird.
[2] In "Sub btnStart_actionPerformed(oEvent2)" wird eine neue CALC-Datei
geöffnet. Sollte eigentlich keinen Unterschied machen, ob man eine
bestehende oder eine neue CALC-Datei öffnet.
Dein von mir modifiziertes Makro schaut nun so aus:
Option Explicit
Sub StartKopfzeile
Dim oDlg as Object
DialogLibraries.LoadLibrary("Standard")
oDlg = createUnoDialog(DialogLibraries.Standard.Dialog1)
oDlg.execute
End Sub
Sub btnStart_actionPerformed(oEvent2)
Dim PV() As New com.sun.star.beans.PropertyValue
StarDesktop.loadComponentFromURL("private:factory/scalc",
"_blank",0,PV())
MsgBox("Last line of ""Sub btnStart_actionPerformed"" ...")
End Sub
Ich hoffe, das geht so in Ordnung, und ich habe nichts
"verschlimmbessert" durch meine (Mini-) Modifikationen Deines Makros
oder etwas entfernt, wodurch Deine Test-Ergebnisse verändert würden.
Test-Ergebnis: Läuft wir geschmiert (LO 6.2.2.2 (x64) @ Windows 7 Home
Premium 64-bit) - auch wenn ich den PC neu gestartet habe.
Aber ich kann ja viel behaupten, deshalb hier der DownloadLink von
"TestDialog.odt": https://www.magentacloud.de/share/npm0d3-mxx
Viele Grüße
Hans-Werner
-- Originalnachricht --
Von: "Gerhard Weydt"
An: users@de.libreoffice.org
Gesendet: 07.04.2019 23:45:05
Betreff: Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice
nach Makrodurchlauf
Hallo Hans-Werner,
deine Mail hattee ich heute früh noch gelesen, mir war klar, dass hinter dem
Syntaxfehler etwas anderes stecken müsse, das ist in x Tests bei mir
durchgelaufen und stammt auch aus Jürgens Code (bis auf die Änderung von global
zu dim, die schon Thomas angesprochen hat).
Der Dialog muss natürlich in jürgens Code fehlen, er hat ja den Dialog mit
vielen Statements selbst generiert und musste zusätzlich Listener für seine
Schaltflächen definieren und diese abfragen. Dafür gibt es manchmal Gründe, und
auch er scheint einen triftigen Grund gehabt zu haben, aber meist ist es
bequemer, den Dialog in der Basic-IDE zu designen und im Dokument zu speichern.
Die Listener werden sicher auch dann gebraucht, bloß übernimmt das dann
LibreOffice im Hintergrund, man muss nur bei Dialog beim gewünschten Ereignis
das auszuführende Makro benennen.
Für unseren Zweck war mir ein möglichst kurzer Code wichtig, damit ein
Entwickler nicht abgeschreckt wird.
Und ein Rückgriff auf Jürgens Dokument ist auch nicht notwendig, der Fehler
tritt auch bei einem leeren Dokument auf, und auch, wenn man ein anderes
LibO-Dokument statt seines Calc-Dokuments lädt.
Da mir daran liegt, dass jemand anders das auch mit meinem Beispiel bestätigt,
bevor ich eine Bugmeldung aufmache, beschreibe ich dir die nötigen Aktionen, es
geht ziemlich schnell, das sieht nur in der Beschreibung so groß aus.
Erzeuge ein neues Writer-Dokument (und speichere am besten gleich, dann hasst
du später nich die Unterbrechung durch den Speichern-Dialog).
Lege einen Makro-Modul an: Extras -> Makros -> Makros verwalten -> LibreOffice
Basic... -> im Explorer links deine Datei auswählen -> New (so steht's in meiner
Version) oder Neu; dann wird dir Module1 als Name vorgeschlagen, für unseren Test brauchen wir
keinen anderen. Nach Bestätigung erscheint die Basic-IDE, wo du den vollständigen Code durch
meine Makros ersetzt (und am besten statt dem Xray irgendeine msgbox nimmst, das ist
einfacher, da hast du recht).
Erzeuge den Dialog: Unten siehst du das Register "Module1". Rechtsklicke rechts
davon, wähle Einfügen -> Basic-Dialog. Dann wird dir ein leerer Dialog angezeigt, Größe
und Titel ist uns wurscht. Nun musst du wahrscheinlich die Symbolleiste
Formular-Steuerelemente einblenden (du kannst sie dann gleich wieder ausblenden) und suchst
dort das Symbol für Schaltfläche, irgendwie wohl ein Rechteck, aber das hängt vom Stil ab,
der Tooltipp zeigt es dir aber, und klickst drauf. Dann kannst du mit der Maus innerhalb
der Dialogfläche ein Rechteck für die Schaltfläche aufziehen, Größe und Position sind
irrelevant, auch der automatisch vergebene Name kann für unsern Zweck bleiben.
Nun fehlt nur noch die Verknüpfung des zweiten Makros mit dem Betätigen der Schaltfläche: Rechtsklick auf die gerade gezeichnete Schaltfläche ->
Eigenschaften -> im linken Teilfenster: Register "Ereignisse" -> Schaltfläche mit den drei Punkten hinter dem Punkt "Aktion
ausführen" betätigen -> Makro...
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Hans-Werner,
deine Mail hattee ich heute früh noch gelesen, mir war klar, dass hinter
dem Syntaxfehler etwas anderes stecken müsse, das ist in x Tests bei mir
durchgelaufen und stammt auch aus Jürgens Code (bis auf die Änderung von
global zu dim, die schon Thomas angesprochen hat).
Der Dialog muss natürlich in jürgens Code fehlen, er hat ja den Dialog
mit vielen Statements selbst generiert und musste zusätzlich Listener
für seine Schaltflächen definieren und diese abfragen. Dafür gibt es
manchmal Gründe, und auch er scheint einen triftigen Grund gehabt zu
haben, aber meist ist es bequemer, den Dialog in der Basic-IDE zu
designen und im Dokument zu speichern. Die Listener werden sicher auch
dann gebraucht, bloß übernimmt das dann LibreOffice im Hintergrund, man
muss nur bei Dialog beim gewünschten Ereignis das auszuführende Makro
benennen.
Für unseren Zweck war mir ein möglichst kurzer Code wichtig, damit ein
Entwickler nicht abgeschreckt wird.
Und ein Rückgriff auf Jürgens Dokument ist auch nicht notwendig, der
Fehler tritt auch bei einem leeren Dokument auf, und auch, wenn man ein
anderes LibO-Dokument statt seines Calc-Dokuments lädt.
Da mir daran liegt, dass jemand anders das auch mit meinem Beispiel
bestätigt, bevor ich eine Bugmeldung aufmache, beschreibe ich dir die
nötigen Aktionen, es geht ziemlich schnell, das sieht nur in der
Beschreibung so groß aus.
Erzeuge ein neues Writer-Dokument (und speichere am besten gleich, dann
hasst du später nich die Unterbrechung durch den Speichern-Dialog).
Lege einen Makro-Modul an: Extras -> Makros -> Makros verwalten ->
LibreOffice Basic... -> im Explorer links deine Datei auswählen -> New
(so steht's in meiner Version) oder Neu; dann wird dir Module1 als Name
vorgeschlagen, für unseren Test brauchen wir keinen anderen. Nach
Bestätigung erscheint die Basic-IDE, wo du den vollständigen Code durch
meine Makros ersetzt (und am besten statt dem Xray irgendeine msgbox
nimmst, das ist einfacher, da hast du recht).
Erzeuge den Dialog: Unten siehst du das Register "Module1". Rechtsklicke
rechts davon, wähle Einfügen -> Basic-Dialog. Dann wird dir ein leerer
Dialog angezeigt, Größe und Titel ist uns wurscht. Nun musst du
wahrscheinlich die Symbolleiste Formular-Steuerelemente einblenden (du
kannst sie dann gleich wieder ausblenden) und suchst dort das Symbol für
Schaltfläche, irgendwie wohl ein Rechteck, aber das hängt vom Stil ab,
der Tooltipp zeigt es dir aber, und klickst drauf. Dann kannst du mit
der Maus innerhalb der Dialogfläche ein Rechteck für die Schaltfläche
aufziehen, Größe und Position sind irrelevant, auch der automatisch
vergebene Name kann für unsern Zweck bleiben.
Nun fehlt nur noch die Verknüpfung des zweiten Makros mit dem Betätigen
der Schaltfläche: Rechtsklick auf die gerade gezeichnete Schaltfläche ->
Eigenschaften -> im linken Teilfenster: Register "Ereignisse" ->
Schaltfläche mit den drei Punkten hinter dem Punkt "Aktion ausführen"
betätigen -> Makro... -> bei "Bibliothek" dein Dokument auklappen, bis
"Module1" erscheint, das anklicken -> rechts "btnStart_actionPerformed"
anklicken. Dann OK und nochmal OK und speichern (das speichert den
Dialog im Dokument und auch das Dokument selbst im Dateisystem).
Dann kannst du testen. Bei mir funktionierte alles, auch nach Schließen
und Wiederöffnen von Libo, erst nach Runterfahren des Rechners und
Wiederstarten tritt der Fehler auf und bleibt dann auch. Was zeigt, dass
nicht etwas im Dokument durch das erstmalige Ausführen geändert wird,
sondern irgendwas Vages, für mich nicht Erratbares im Zusammenspiel von
BS, LibO und Dokument passiert.
Wenn ich das Dokument anschließend mit 5.3.3.1 öffne, läuft weiterhin
alles durch, mit 6.0.7.3 nicht; dazwischen habe ich derzeit keine
Version installiert. Das deckt sich mit Jürgens Feststellung, dass sein
Makro früher lief, wiewohl nicht exakt mit seiner Angabe, aber darauf
kommt es ja nicht an, wichtig ist, dass da was passiert ist, was diesen
Nebeneffekt hat. Ich werde das in nächster Zeit eingrenzen.
Grüße
Gerhard
Am 07.04.2019 um 18:43 schrieb OoOHWHOoO:
KORREKTUR zu https://listarchives.libreoffice.org/de/users/msg21513.html
Da muss wohl beim Kopieren aus der Mail
https://listarchives.libreoffice.org/de/users/msg21512.html irgend
etwas in die Windows-Zwischenablage geraten sein.
Jetzt kommt kein Syntaxfehler mehr und LO stürzt auch nicht ab.
Jetzt bezüglich Zeile "oDlg =
createUnoDialog(DialogLibraries.Standard.Dialog1)" die Fehlermeldung:
BASIC-Laufzeitfehler.
Eigenschaft oder Methode nicht gefunden: Dialog1
Da fehlt wohl ein "Dialog1". Woher nehmen wenn nicht stehlen ... jetzt
mag ich nicht mehr mit meinem Makro-Dialog-Minimalwissen :-(( ...
Grüße
Hans-Werner ;-))
Gerhards Makro (
https://listarchives.libreoffice.org/de/users/msg21512.html ):
Option Explicit
Sub StartKopfzeile
dim oDlg as Object ' Dialogfenster
DialogLibraries.LoadLibrary("Standard") 'auch ein
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
KORREKTUR zu https://listarchives.libreoffice.org/de/users/msg21513.html
Da muss wohl beim Kopieren aus der Mail
https://listarchives.libreoffice.org/de/users/msg21512.html irgend etwas
in die Windows-Zwischenablage geraten sein.
Jetzt kommt kein Syntaxfehler mehr und LO stürzt auch nicht ab.
Jetzt bezüglich Zeile "oDlg =
createUnoDialog(DialogLibraries.Standard.Dialog1)" die Fehlermeldung:
BASIC-Laufzeitfehler.
Eigenschaft oder Methode nicht gefunden: Dialog1
Da fehlt wohl ein "Dialog1". Woher nehmen wenn nicht stehlen ... jetzt
mag ich nicht mehr mit meinem Makro-Dialog-Minimalwissen :-(( ...
Grüße
Hans-Werner ;-))
Gerhards Makro (
https://listarchives.libreoffice.org/de/users/msg21512.html ):
Option Explicit
Sub StartKopfzeile
dim oDlg as Object ' Dialogfenster
DialogLibraries.LoadLibrary("Standard")'auch ein fester Dialog
bringt keine Änderung
oDlg = createUnoDialog(DialogLibraries.Standard.Dialog1)
oDlg.execute
End Sub
REM Aktion Pseudo-Kopfzeilen eintragen und formatieren
Sub btnStart_actionPerformed(oEvent2)
dim oDocC as Object
Dim sUrl as String
sUrl = converttoUrl("E:\TMP\Kopfzeilen_Texte.ods") ' MODIFIZIERT !
Dim zFileProperties() As New com.sun.star.beans.PropertyValue
oDocC = StarDesktop.loadComponentFromURL(sURL, "_blank", 0,
zFileProperties())
MsgBox("HALLO") ' MODIFIZIERT !
End Sub
--
Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org
Probleme?
https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/users/
Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Guten Morgen Gerhard,
ich habe mal folgendes gemacht:
[0] LO 6.2.2.2 (x64) @ Windows 7 Home Premium 64-bit
[1] Mit https://c.web.de/@693152299987503749/RJCw-SFyQFK1cq8oL0FtFA
nochmals Juergens zip-Datei heruntergeladen.
[2] "Musterdateien_02.zip" entpackt und abgespeichert:
"E:\TMP\Kopfzeilen_Texte.ods" und "E:\TMP\Musterbuch mit Makro_06.odt".
[3] Nun habe ich in "Musterbuch mit Makro_06.odt" das enthaltene Makro
gelöscht, Dein Makro aus Deiner Mail kopiert und dort eingefügt.
[4] An Deinem Makro habe ich nur 2 Modifikationen vorgenommen:
sUrl =
converttoUrl("C:\Users\gerha\Gerhard\zwi\Musterdateien_02\Kopfzeilen_Texte.ods")
zu
sUrl = converttoUrl("E:\TMP\Kopfzeilen_Texte.ods")
und
Xray oDocC
zu
MsgBox("MsgBox ("HELLO WORLD")
[5] "Musterbuch mit Makro_06.odt" gespeichert und wieder geöffnet.
[6] Wenn ich nun die Schaltfläche "Start Texte eintragen" anklicke,
dann:
[6.1] Öffnet die BASIC-IDE und es wird die Meldung "BASIC-Syntaxfehler.
Syntakfehler" angezeigt.
[6.2] Der rote Pfeil in der BASIC-IDE zeigt auf die Zeile "dim oDlg as
Object ' Dialogfenster" und der Cursor steht direkt hinter
"Object".
[6.3] Klicke ich nun das "OK" der Fehlermeldungs-MsgBox an, stürzt LO
komplett ab.
[6.4] Öffne ich nun wieder "Musterbuch mit Makro_06.odt", meldet sich
LO, stellt fest, dass LO abgestürzt ist und fragt, ob ich eine
Fehlermeldung senden möchte.
[7] Starte ich direkt in der BASIC-IDE "Sub StartKopfzeile" kommt [6.1]
und [6.2], aber bei Klick auf das "OK" der Fehlermeldungs-MsgBox stürzt
LO nicht ab.
So kann ich Dein Makro nicht testen wie von Dir beschrieben. Bitte
bedenke aber, dass ich bezüglich BASIC-MAKO-DIALOG-Programmierung über
keinerlei Wissen oder Erfahrungswerte verfüge, also mehr "formal" als
"inhaltlich" getestet habe.
Grüße
Hans-Werner
Die von mir modifizierte Variante Deines Makros:
Option Explicit
Sub StartKopfzeile
dim oDlg as Object ' Dialogfenster
DialogLibraries.LoadLibrary("Standard")'auch ein fester Dialog
bringt keine Änderung
oDlg = createUnoDialog(DialogLibraries.Standard.Dialog1)
oDlg.execute
End Sub
REM Aktion Pseudo-Kopfzeilen eintragen und formatieren
Sub btnStart_actionPerformed(oEvent2)
dim oDocC as Object
Dim sUrl as String
sUrl = converttoUrl("E:\TMP\Kopfzeilen_Texte.ods")
Dim zFileProperties() As New com.sun.star.beans.PropertyValue
oDocC = StarDesktop.loadComponentFromURL(sURL, "_blank", 0,
zFileProperties())
MsgBox ("HELLO WORLD")
End Sub
-- Originalnachricht --
Von: "Gerhard Weydt"
An: users@de.libreoffice.org
Gesendet: 07.04.2019 01:39:47
Betreff: Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice
nach Makrodurchlauf
Hallo Jürgen, Hans-Werner,
ich habe inzwischen das Makro auf eine ziemlich minimale Version reduziert, bei
der der Fehler immer noch auftritt:
Option Explicit
Sub StartKopfzeile
dim oDlg as Object ' Dialogfenster
DialogLibraries.LoadLibrary("Standard")'auch ein fester Dialog bringt
keine Änderung
oDlg = createUnoDialog(DialogLibraries.Standard.Dialog1)
oDlg.execute
End Sub
REM Aktion Pseudo-Kopfzeilen eintragen und formatieren
Sub btnStart_actionPerformed(oEvent2)
dim oDocC as Object
Dim sUrl as String
sUrl =
converttoUrl("C:\Users\gerha\Gerhard\zwi\Musterdateien_02\Kopfzeilen_Texte.ods")
Dim zFileProperties() As New com.sun.star.beans.PropertyValue
oDocC = StarDesktop.loadComponentFromURL(sURL, "_blank", 0,
zFileProperties())
Xray oDocC
End Sub
wobei statt dem Xray auch eine Msgbox stehen könnte. Die wenigen Deklarationen
sind nun alle in den einzelnen Routinen enthalten.
Weiter habe ich herausgefunden, dass das folgende Verhalten wiederholbar
auftritt:
erzeuge ich ein neues Writer-Dokument, in das ich die Schaltfläche zum Starten
des Makros aus dem früheren Dokument kopiere, und füge ich dem Dokument dann
auch per Kopieren die beiden obigen Makros hinzu, erzeuge einen neuen Dialog,
dem ich wieder per Kopieren die einzige Schaltfläche hinzufüge, die das Makro
btnStart_actionPerformed aufruft, dann:
* läuft alles bis zum Ende durch, auch beim zweiten Aufruf, auch nach
Schließen und Wiederöffnen von LibO und erneutem Laden des neuen
Dokuments
* Libo bleibt aber hängen, wenn der Rechner runter- und wieder
raufgefahren wurde und ich dann nach erneutem Laden des Dokuments
die Schaltfläche bediene.
Das ist nun ein Verhalten, mit dem ich nichts anfangen kann, ich habe keine
Idee, was anders sein soll, wenn das Dokument seit dem letzten
Betriebssystemstart erzeugt wurde oder schon früher. Am Dokument selbst ist
nichts erkennbar, ich habe die verschiedenen Stände der einzelnen Dateien des
entzippten Dokuments mit
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Jürgen, Hans-Werner,
ich habe inzwischen das Makro auf eine ziemlich minimale Version
reduziert, bei der der Fehler immer noch auftritt:
Option Explicit
Sub StartKopfzeile
dim oDlg as Object ' Dialogfenster
DialogLibraries.LoadLibrary("Standard") 'auch ein fester Dialog
bringt keine Änderung
oDlg = createUnoDialog(DialogLibraries.Standard.Dialog1)
oDlg.execute
End Sub
REM Aktion Pseudo-Kopfzeilen eintragen und formatieren
Sub btnStart_actionPerformed(oEvent2)
dim oDocC as Object
Dim sUrl as String
sUrl =
converttoUrl("C:\Users\gerha\Gerhard\zwi\Musterdateien_02\Kopfzeilen_Texte.ods")
Dim zFileProperties() As New com.sun.star.beans.PropertyValue
oDocC = StarDesktop.loadComponentFromURL(sURL, "_blank", 0,
zFileProperties())
Xray oDocC
End Sub
wobei statt dem Xray auch eine Msgbox stehen könnte. Die wenigen
Deklarationen sind nun alle in den einzelnen Routinen enthalten.
Weiter habe ich herausgefunden, dass das folgende Verhalten wiederholbar
auftritt:
erzeuge ich ein neues Writer-Dokument, in das ich die Schaltfläche zum
Starten des Makros aus dem früheren Dokument kopiere, und füge ich dem
Dokument dann auch per Kopieren die beiden obigen Makros hinzu, erzeuge
einen neuen Dialog, dem ich wieder per Kopieren die einzige Schaltfläche
hinzufüge, die das Makro btnStart_actionPerformed aufruft, dann:
* läuft alles bis zum Ende durch, auch beim zweiten Aufruf, auch nach
Schließen und Wiederöffnen von LibO und erneutem Laden des neuen
Dokuments
* Libo bleibt aber hängen, wenn der Rechner runter- und wieder
raufgefahren wurde und ich dann nach erneutem Laden des Dokuments
die Schaltfläche bediene.
Das ist nun ein Verhalten, mit dem ich nichts anfangen kann, ich habe
keine Idee, was anders sein soll, wenn das Dokument seit dem letzten
Betriebssystemstart erzeugt wurde oder schon früher. Am Dokument selbst
ist nichts erkennbar, ich habe die verschiedenen Stände der einzelnen
Dateien des entzippten Dokuments miteinander verglichen (hatte ich
eigentlich auch nicht erwartet). Es kann natürlich sein, dass LibO beim
Herunterfahren nicht spurlos verschwindet, sondern irgend etwas
vorhanden bleibt, was erst beim BS-Runterfahren gelöscht wird, aber da
kenne ich mich überhaupt nicht aus.
Ich kann da nichts mehr rauskriegen, man kann das Problem in dieser
einfachen Form als Bug melden, das ist ein Thema für die Kenner der
Innereien
Gruß
Gerhard
Am 07.04.2019 um 00:51 schrieb OoOHWHOoO:
Hallo Juergen,
mit recht hoher Wahrscheinlichkeit liegt bei Dir wohl kein
FilePicker-Problem im Sinne meines BugReports
(https://bugs.documentfoundation.org/show_bug.cgi?id=124579) vor,
sondern wohl eher ein anderes Problem. Damit das FilePicker-Problem
(im Sinne meines BugReports) auftritt ist Voraussetzung, das LO NICHT
LÄUFT und man den FilePicker mit einem EXTERNEN Kommando startet.
Siehe auch (https://bugs.documentfoundation.org/show_bug.cgi?id=123502):
"[...] Just wanted to note that the way to run the macro from command
prompt, like
> instdir/program/soffice.bin --nologo
macro:///Standard.Module1.TestPickerSW
without LO already running, is essential to reproduce the problem from
comment 19 [...]"
Beide Voraussetzungen sind bei Deiner Anwendung wohl eher nicht erfüllt:
[1] Wenn man Deine Datei "Muster Dialog und Datei-OP v01.odt" öffnet
wird ja LO gestartet und läuft somit bereits, wenn man die ROTE
Schaltfläche auslöst.
[2] Der Start des FilePickers über eine Schaltfläche bei laufendem LO
ist wohl eher auch kein externer Aufruf eines Makros, welches einen
FilePicker-Aufruf enthält.
[3] Außerdem ist bei meinem BugReport NUR der
Betriebssystem-FilePicker und -FolderPicker betroffen.
Außerdem ist es nicht gerade in sich schlüssig an ein
FilePicker-Problem zu denken, wenn der FilePicker mit der ROTEN
Schaltfläche nicht funktioniert und mit den GRÜNEN Schaltflächen doch,
zumal bei Deiner Problematik ja auch beide FilePicker betroffen sind.
Da müsste mal jemand, der sich mit dieser Dialog-Programmierung
auskennt, untersuchen, ob die ROTE Schaltfläche irgendwie
programmier-technisch fehlerbehaftet ist. Mit
BASIC-Makro-Dialog-Programmierung habe ich keinerlei Erfahrung, kann
Dir hier also nicht weiter helfen.
Was mir allerdings aufgefallen ist: Bei meiner
Makro-HangUp-Problematik zeigt der TaskManager für soffice.bin eine
CPU-Last = 0 an, bei Deiner Makro-HangUp-Problematik zeigt der
TaskManager für soffice.bin eine CPU-Last = 25 an, was wohl ein
Hinweis darauf sein kann, dass da irgend etwas wie doll in einer
"Schleife" läuft und so LO verhindert ist Benutzereingaben anzunehmen.
Ist nur mal eine spekulative Vermutung ...
Grüße
Hans-Werner
-- Originalnachricht --
Von: "Jürgen Klatt"
An: users@de.libreoffice.org
Gesendet: 06.04.2019 21:30:58
Betreff: Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice
nach Mak
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Juergen,
mit recht hoher Wahrscheinlichkeit liegt bei Dir wohl kein
FilePicker-Problem im Sinne meines BugReports
(https://bugs.documentfoundation.org/show_bug.cgi?id=124579) vor,
sondern wohl eher ein anderes Problem. Damit das FilePicker-Problem (im
Sinne meines BugReports) auftritt ist Voraussetzung, das LO NICHT LÄUFT
und man den FilePicker mit einem EXTERNEN Kommando startet.
Siehe auch (https://bugs.documentfoundation.org/show_bug.cgi?id=123502):
"[...] Just wanted to note that the way to run the macro from command
prompt, like
> instdir/program/soffice.bin --nologo
macro:///Standard.Module1.TestPickerSW
without LO already running, is essential to reproduce the problem from
comment 19 [...]"
Beide Voraussetzungen sind bei Deiner Anwendung wohl eher nicht erfüllt:
[1] Wenn man Deine Datei "Muster Dialog und Datei-OP v01.odt" öffnet
wird ja LO gestartet und läuft somit bereits, wenn man die ROTE
Schaltfläche auslöst.
[2] Der Start des FilePickers über eine Schaltfläche bei laufendem LO
ist wohl eher auch kein externer Aufruf eines Makros, welches einen
FilePicker-Aufruf enthält.
[3] Außerdem ist bei meinem BugReport NUR der Betriebssystem-FilePicker
und -FolderPicker betroffen.
Außerdem ist es nicht gerade in sich schlüssig an ein FilePicker-Problem
zu denken, wenn der FilePicker mit der ROTEN Schaltfläche nicht
funktioniert und mit den GRÜNEN Schaltflächen doch, zumal bei Deiner
Problematik ja auch beide FilePicker betroffen sind. Da müsste mal
jemand, der sich mit dieser Dialog-Programmierung auskennt, untersuchen,
ob die ROTE Schaltfläche irgendwie programmier-technisch fehlerbehaftet
ist. Mit BASIC-Makro-Dialog-Programmierung habe ich keinerlei Erfahrung,
kann Dir hier also nicht weiter helfen.
Was mir allerdings aufgefallen ist: Bei meiner Makro-HangUp-Problematik
zeigt der TaskManager für soffice.bin eine CPU-Last = 0 an, bei Deiner
Makro-HangUp-Problematik zeigt der TaskManager für soffice.bin eine
CPU-Last = 25 an, was wohl ein Hinweis darauf sein kann, dass da irgend
etwas wie doll in einer "Schleife" läuft und so LO verhindert ist
Benutzereingaben anzunehmen. Ist nur mal eine spekulative Vermutung ...
Grüße
Hans-Werner
-- Originalnachricht --
Von: "Jürgen Klatt"
An: users@de.libreoffice.org
Gesendet: 06.04.2019 21:30:58
Betreff: Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice
nach Makrodurchlauf
Hallo,
Am 06.04.2019 um 18:45 schrieb OoOHWHOoO:
Wen es interessiert:
Ja, es interessiert mich sehr, auch wenn zwischen
meinen Rückmeldungen größere Pausen liegen.
Bin sehr damit beschäftigt alle Inputs und meine neuen Ideen zu verarbeiten.
Auch mein Jagdinstinkt ist ungebrochen.
Zwecks weiterer Analyse habe auch ich meinen ursprünglichen Code
abgespeckt und zwecks besserer Übersicht auf zwei Module verteilt.
Siehe diese abgespeckte Version:
https://c.web.de/@693152299987503749/x5wk8EanTm2HOLpD8pVtfw
Weitere Beschreibungen siehe Datei.
Filepicker Problem oder doch noch etwas anderes???
Beide Module können unabhängig voneinander gestartet werden.
Das abgespeckte Programm habe ich mit folgenden LibO-Versionen getestet:
a) 6.2.1.2 (x64)
Build-ID: 7bcb35dc3024a62dea0caee87020152d1ee96e71
b) Portable 6.1.4.2
Build-ID: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3
c) 6.3.0.0.alpha0+ (x64) (Master) vom 05.04.2019
Build ID: 35d9a2618dc0116378ab795a7b9277d248c5afd4
Viele Grüße und Danke
Jürgen
Am 06.04.2019 um 18:45 schrieb OoOHWHOoO:
Wen es interessiert:
BugReport - "Basic Macro hang up when using (operation system)
filepicker/folderpicker"
https://bugs.documentfoundation.org/show_bug.cgi?id=124579
"[...] Reproducible with current master on Windows 10 x64. [...]"
https://bugs.documentfoundation.org/show_bug.cgi?id=124579#c3
Das ursächliche Problem wurde auch schon von dem LO-Entwickler
identifiziert:
"[...] tdf#124579: ensure to provide an event to wake up main loop
when notifying
Without that, Request::waitProcessMessages might wait indefinitely for
Application::Yield() to return; while the latter would wait for a
message in PeekMessage. If there's no visible LO window, the message
might never arrive by itself. [...]"
https://gerrit.libreoffice.org/#/c/70346/
Wer selber mit den "attached files" ("macro for testing picker
software" und "win cmd for starting macro") des BugReports testen
will, sollte unbedingt darauf achten, dass vor dem Start von "win cmd
for starting macro" LibreOffice NICHT läuft ! So eine Situation kann
es z.B. geben, wenn man ein Makro aus einem anderen Programm heraus
(beispielsweise "Perl") startet.
Grüße
Hans-Werner
-- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org
Probleme?
https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchiv
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo,
Am 06.04.2019 um 18:45 schrieb OoOHWHOoO:
Wen es interessiert:
Ja, es interessiert mich sehr, auch wenn zwischen
meinen Rückmeldungen größere Pausen liegen.
Bin sehr damit beschäftigt alle Inputs und meine neuen Ideen zu verarbeiten.
Auch mein Jagdinstinkt ist ungebrochen.
Zwecks weiterer Analyse habe auch ich meinen ursprünglichen Code
abgespeckt und zwecks besserer Übersicht auf zwei Module verteilt.
Siehe diese abgespeckte Version:
https://c.web.de/@693152299987503749/x5wk8EanTm2HOLpD8pVtfw
Weitere Beschreibungen siehe Datei.
Filepicker Problem oder doch noch etwas anderes???
Beide Module können unabhängig voneinander gestartet werden.
Das abgespeckte Programm habe ich mit folgenden LibO-Versionen getestet:
a) 6.2.1.2 (x64)
Build-ID: 7bcb35dc3024a62dea0caee87020152d1ee96e71
b) Portable 6.1.4.2
Build-ID: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3
c) 6.3.0.0.alpha0+ (x64) (Master) vom 05.04.2019
Build ID: 35d9a2618dc0116378ab795a7b9277d248c5afd4
Viele Grüße und Danke
Jürgen
Am 06.04.2019 um 18:45 schrieb OoOHWHOoO:
Wen es interessiert:
BugReport - "Basic Macro hang up when using (operation system)
filepicker/folderpicker"
https://bugs.documentfoundation.org/show_bug.cgi?id=124579
"[...] Reproducible with current master on Windows 10 x64. [...]"
https://bugs.documentfoundation.org/show_bug.cgi?id=124579#c3
Das ursächliche Problem wurde auch schon von dem LO-Entwickler
identifiziert:
"[...] tdf#124579: ensure to provide an event to wake up main loop
when notifying
Without that, Request::waitProcessMessages might wait indefinitely for
Application::Yield() to return; while the latter would wait for a
message in PeekMessage. If there's no visible LO window, the message
might never arrive by itself. [...]"
https://gerrit.libreoffice.org/#/c/70346/
Wer selber mit den "attached files" ("macro for testing picker
software" und "win cmd for starting macro") des BugReports testen
will, sollte unbedingt darauf achten, dass vor dem Start von "win cmd
for starting macro" LibreOffice NICHT läuft ! So eine Situation kann
es z.B. geben, wenn man ein Makro aus einem anderen Programm heraus
(beispielsweise "Perl") startet.
Grüße
Hans-Werner
--
Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org
Probleme?
https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/users/
Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Wen es interessiert:
BugReport - "Basic Macro hang up when using (operation system)
filepicker/folderpicker"
https://bugs.documentfoundation.org/show_bug.cgi?id=124579
"[...] Reproducible with current master on Windows 10 x64. [...]"
https://bugs.documentfoundation.org/show_bug.cgi?id=124579#c3
Das ursächliche Problem wurde auch schon von dem LO-Entwickler
identifiziert:
"[...] tdf#124579: ensure to provide an event to wake up main loop when
notifying
Without that, Request::waitProcessMessages might wait indefinitely for
Application::Yield() to return; while the latter would wait for a
message in PeekMessage. If there's no visible LO window, the message
might never arrive by itself. [...]"
https://gerrit.libreoffice.org/#/c/70346/
Wer selber mit den "attached files" ("macro for testing picker software"
und "win cmd for starting macro") des BugReports testen will, sollte
unbedingt darauf achten, dass vor dem Start von "win cmd for starting
macro" LibreOffice NICHT läuft ! So eine Situation kann es z.B. geben,
wenn man ein Makro aus einem anderen Programm heraus (beispielsweise
"Perl") startet.
Grüße
Hans-Werner
--
Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org
Probleme?
https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/users/
Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
" & Chr(10) & "Exit Macro ...")
End If
Case ""
End
Case Else
MsgBox("Wrong input: " & D & Chr(10) & "Exit macro ...")
End
End Select
MsgBox ("Last code line of macro ...")
End Sub
+ TestPickerSW.cmd
SET L="C:/Program Files/LibreOffice/program/soffice.exe"
SET M="macro:///Standard.Test.TestPickerSW()"
%L% --nologo %M%
REM Please notice:
REM
REM L="C:/Program Files/LibreOffice/program/soffice.exe"
REM
REM May be that this path of "soffice.exe" has to be modified due to
your installation of Libre Office.
REM
REM M="macro:///Standard.Test.TestPickerSW()"
REM
REM "Standard" = User's library (BASIC-IDE).
REM "Test" = Module "Test" in the user's library.
REM If not existing, please create such a module.
REM "TestPickerSW" = Macro "Sub TestPickerSW" (File: TestPickerSW.txt).
REM Please copy this macro in the module "Test".
-- Originalnachricht --
Von: "Gerhard Weydt"
An: users@de.libreoffice.org
Gesendet: 06.04.2019 00:05:31
Betreff: Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice
nach Makrodurchlauf
Hallo Jürgen, Hans-Werner,
das "eingedampfte" Makro, das ich in meiner Mail vom 3.4. mitgeteilt habe,
zeigt das Phänomen, bei Aufruf per Schaltfläche hängenzubleiben, aber bei direktem Aufruf
durchzulaufen, enthält aber gar keine File Picker! Daher kann ich mir nicht vorstellen,
dass es am File Picker liegen sollte.
Was ich allerdings nun nicht mehr nachvollziehen kann, ist das mein neu
aufgebautes Dokument den Fehler nicht mehr produzieren soll, nun verhält es
sich genauso wie das von Jürgen erhaltene Dokument, beide mit dem reduzierten
Code. Da ich aber doch darauf schwören möchte, dass ich mich nicht getäuscht
habe, weckt das meinen Jagdinstinkt, und ich werde weiter rumprobieren.
Aber diese beiden Bemerkiungen wollte ich doch gleich nach dem Lesen der
Nachricht loslassen.
Gruß
Gerhard
Am 05.04.2019 um 13:37 schrieb OoOHWHOoO:
Hallo Juergen & *,
nachdem Gerhard festgestellt hatte (https://listarchives.libreoffice.org/de/users/msg21491.html), dass Dein
Makro bei direktem Start von "StartKopfzeile" in der BASIC-IDE (interner Start) fehlerfrei läuft im
Gegensatz zum Start über die Schaltfläche "Start Texte eintragen" in der Datei "Musterbuch mit
Makro_06.odt" (externer Start), habe ich mir überlegt zu schauen, was passiert, wenn man Dein Makro über
ein Windows-CMD extern startet, was ja auch eine Form des externen Makro-Starts darstellt.
Da mir Dein Makro (für eventuelle Fehlersuche) durch die vielen SUBs und
FUNCTIONs zu unübersichtlich ist, habe ich es mal neu geschrieben auf Basis des
von Dir verwendeten Algorithmus.
Das (neue) Makro läuft fehlerhaft, wenn man den Betriebssystem-FilePicker
"com.sun.star.ui.dialogs.FilePicker" auswählt.
Im Kontext der von Oliver und mir festgestellten Probleme mit dem
Betriebssystem-FolderPicker "com.sun.star.ui.dialogs.FolderPicker" scheint es
mir doch nun sehr wahrscheinlich, dass da ein Problem mit der Picker-Software vorliegt,
wenn man die Betriebssystem-Versionen der Picker-Software verwendet - also auch Deine
Probleme mit Deinem Makro wohl damit zusammenhängen.
Gruß
Hans-Werner
[1] Ergebnis (Systemumgebung: LO 6.2.2.2 (x64) @ Windows 7 Home Premium 64-bit)
[1.1] Verwendet man für die Dateiauswahl den Betriebssystem-FilePicker
("com.sun.star.ui.dialogs.FilePicker"), bleibt das Makro nach der Dateiauswahl
hängen.
[1.2] Verwendet man für die Dateiauswahl den Office-FilePicker
("com.sun.star.ui.dialogs.OfficeFilePicker"), läuft das Makro fehlerfrei durch.
[1.3] Verwendet man in Deinem Makro den Office-FilePicker
("com.sun.star.ui.dialogs.OfficeFilePicker"), hat dies keine Auswirkung auf das
Hängenbleiben bei dem MsgBox-Aufruf. Ich spekuliere mal, dass da wohl vielleicht noch
andere ungünstige Randbedingungen auftreten, die den FilePicker-Fehler kaschieren oder
auch der FilePicker-Fehler selbst andere Fehler verursacht.
[2] Das "neue" Makro
[2.1] Die Dialog-Sachen (Schaltfläche "Start Texte eintragen") habe ich durch
eine einfache InputBox ersetzt.
[2.2] Die Datei "CALC.ods" ist eine unveränderte Kopie Deiner Datei
"Kopfzeilen_Texte.ods".
[2.3] Die Datei "WRITER.odt" ist eine Kopie Deiner Datei "Musterbuch mit
Makro_06.odt", wobei ich lediglich
+ Dein Makro "modKopfzeile" entfernt habe.
+ die Schaltfläche "Start Texte eintragen" entfernt habe.
[2.4] Soweit ich es überschaut habe, liefert mein Makro das gleiche Ergebnis
wie Dein Makro (identische Seitenzahl von 249 Seiten und entsprechende
Kopfzeilen-Einträge, aber auf der letzten Seite (249) gibt es eine (kleine)
Abweichung:
+ Dein Makro: "Mein Text Links 10" und "Mein Text
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Jürgen, Hans-Werner,
das "eingedampfte" Makro, das ich in meiner Mail vom 3.4. mitgeteilt
habe, zeigt das Phänomen, bei Aufruf per Schaltfläche hängenzubleiben,
aber bei direktem Aufruf durchzulaufen, enthält aber gar keine File
Picker! Daher kann ich mir nicht vorstellen, dass es am File Picker
liegen sollte.
Was ich allerdings nun nicht mehr nachvollziehen kann, ist das mein neu
aufgebautes Dokument den Fehler nicht mehr produzieren soll, nun verhält
es sich genauso wie das von Jürgen erhaltene Dokument, beide mit dem
reduzierten Code. Da ich aber doch darauf schwören möchte, dass ich mich
nicht getäuscht habe, weckt das meinen Jagdinstinkt, und ich werde
weiter rumprobieren.
Aber diese beiden Bemerkiungen wollte ich doch gleich nach dem Lesen der
Nachricht loslassen.
Gruß
Gerhard
Am 05.04.2019 um 13:37 schrieb OoOHWHOoO:
Hallo Juergen & *,
nachdem Gerhard festgestellt hatte
(https://listarchives.libreoffice.org/de/users/msg21491.html), dass
Dein Makro bei direktem Start von "StartKopfzeile" in der BASIC-IDE
(interner Start) fehlerfrei läuft im Gegensatz zum Start über die
Schaltfläche "Start Texte eintragen" in der Datei "Musterbuch mit
Makro_06.odt" (externer Start), habe ich mir überlegt zu schauen, was
passiert, wenn man Dein Makro über ein Windows-CMD extern startet, was
ja auch eine Form des externen Makro-Starts darstellt.
Da mir Dein Makro (für eventuelle Fehlersuche) durch die vielen SUBs
und FUNCTIONs zu unübersichtlich ist, habe ich es mal neu geschrieben
auf Basis des von Dir verwendeten Algorithmus.
Das (neue) Makro läuft fehlerhaft, wenn man den
Betriebssystem-FilePicker "com.sun.star.ui.dialogs.FilePicker" auswählt.
Im Kontext der von Oliver und mir festgestellten Probleme mit dem
Betriebssystem-FolderPicker "com.sun.star.ui.dialogs.FolderPicker"
scheint es mir doch nun sehr wahrscheinlich, dass da ein Problem mit
der Picker-Software vorliegt, wenn man die Betriebssystem-Versionen
der Picker-Software verwendet - also auch Deine Probleme mit Deinem
Makro wohl damit zusammenhängen.
Gruß
Hans-Werner
[1] Ergebnis (Systemumgebung: LO 6.2.2.2 (x64) @ Windows 7 Home
Premium 64-bit)
[1.1] Verwendet man für die Dateiauswahl den Betriebssystem-FilePicker
("com.sun.star.ui.dialogs.FilePicker"), bleibt das Makro nach der
Dateiauswahl hängen.
[1.2] Verwendet man für die Dateiauswahl den Office-FilePicker
("com.sun.star.ui.dialogs.OfficeFilePicker"), läuft das Makro
fehlerfrei durch.
[1.3] Verwendet man in Deinem Makro den Office-FilePicker
("com.sun.star.ui.dialogs.OfficeFilePicker"), hat dies keine
Auswirkung auf das Hängenbleiben bei dem MsgBox-Aufruf. Ich spekuliere
mal, dass da wohl vielleicht noch andere ungünstige Randbedingungen
auftreten, die den FilePicker-Fehler kaschieren oder auch der
FilePicker-Fehler selbst andere Fehler verursacht.
[2] Das "neue" Makro
[2.1] Die Dialog-Sachen (Schaltfläche "Start Texte eintragen") habe
ich durch eine einfache InputBox ersetzt.
[2.2] Die Datei "CALC.ods" ist eine unveränderte Kopie Deiner Datei
"Kopfzeilen_Texte.ods".
[2.3] Die Datei "WRITER.odt" ist eine Kopie Deiner Datei "Musterbuch
mit Makro_06.odt", wobei ich lediglich
+ Dein Makro "modKopfzeile" entfernt habe.
+ die Schaltfläche "Start Texte eintragen" entfernt habe.
[2.4] Soweit ich es überschaut habe, liefert mein Makro das gleiche
Ergebnis wie Dein Makro (identische Seitenzahl von 249 Seiten und
entsprechende Kopfzeilen-Einträge, aber auf der letzten Seite (249)
gibt es eine (kleine) Abweichung:
+ Dein Makro: "Mein Text Links 10" und "Mein Text Rechts 10Mein Text
Rechts 10Mein Text Rechts 10"
+ Mein Makro: "Mein Text Links 10" und "Mein Text Rechts 10"
[2.5] Falls Du weitere Abweichungen oder Fehlfunktionen in dem (neuen)
Makro feststellen solltest, so melde Dich bitte.
[3] Hinweise:
[3.1] Makro (Download-Datei: Kopfzeilen.txt)
Das (neue) Makro besteht aus der "Sub Kopfzeilen" und der "Function
DateiAuswahl".
[3.2] Windows-CMD (Download-Datei: Kopfzeilen.cmd)
Damit kann man das Makro (unter Windows) extern starten (für Linux
entsprechend BASH-Syntax):
SET L="C:/Program Files/LibreOffice/program/soffice.exe"
SET M="macro:///Standard.Kopfzeilen.Kopfzeilen()"
%L% --nologo %M%
Mit:
+ Der Speicherpfad von "soffice.exe", muss gegebenenfalls angepasst
werden:
SET L="C:/Program Files/LibreOffice/program/soffice.exe"
+ Der Speicherpfad des Makros:
SET M="macro:///Standard.Kopfzeilen.Kopfzeilen()"
+ Standard = Bibliothek = "[Meine Makros & Dialoge].Standard"
+ Kopfzeilen = Modul = "Kopfzeilen"
+ Kopfzeilen() = Makro (im Modul "Kopfzeilen")
Wenn Du das Makro in der BASIC-IDE nicht in einem Modul abspeicherst,
dann nur: SET M="macro:///Standard.Kopfzeilen()"
[3.3] CALC.ods
Siehe [2.2] !
[3.4] WRITER.odt
Siehe [3.2] !
[3.5] Download-Link
https://www.magentacloud.de/share/r8eyn.v.s0
enthält:
Kopfzeilen.txt
Kopzeilen.cmd
WRITER.odt
CALC.ods
[4] Marko-Code
Dies nur zur Vorschau. Der
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Juergen & *,
nachdem Gerhard festgestellt hatte
(https://listarchives.libreoffice.org/de/users/msg21491.html), dass Dein
Makro bei direktem Start von "StartKopfzeile" in der BASIC-IDE (interner
Start) fehlerfrei läuft im Gegensatz zum Start über die Schaltfläche
"Start Texte eintragen" in der Datei "Musterbuch mit Makro_06.odt"
(externer Start), habe ich mir überlegt zu schauen, was passiert, wenn
man Dein Makro über ein Windows-CMD extern startet, was ja auch eine
Form des externen Makro-Starts darstellt.
Da mir Dein Makro (für eventuelle Fehlersuche) durch die vielen SUBs und
FUNCTIONs zu unübersichtlich ist, habe ich es mal neu geschrieben auf
Basis des von Dir verwendeten Algorithmus.
Das (neue) Makro läuft fehlerhaft, wenn man den
Betriebssystem-FilePicker "com.sun.star.ui.dialogs.FilePicker" auswählt.
Im Kontext der von Oliver und mir festgestellten Probleme mit dem
Betriebssystem-FolderPicker "com.sun.star.ui.dialogs.FolderPicker"
scheint es mir doch nun sehr wahrscheinlich, dass da ein Problem mit der
Picker-Software vorliegt, wenn man die Betriebssystem-Versionen der
Picker-Software verwendet - also auch Deine Probleme mit Deinem Makro
wohl damit zusammenhängen.
Gruß
Hans-Werner
[1] Ergebnis (Systemumgebung: LO 6.2.2.2 (x64) @ Windows 7 Home Premium
64-bit)
[1.1] Verwendet man für die Dateiauswahl den Betriebssystem-FilePicker
("com.sun.star.ui.dialogs.FilePicker"), bleibt das Makro nach der
Dateiauswahl hängen.
[1.2] Verwendet man für die Dateiauswahl den Office-FilePicker
("com.sun.star.ui.dialogs.OfficeFilePicker"), läuft das Makro fehlerfrei
durch.
[1.3] Verwendet man in Deinem Makro den Office-FilePicker
("com.sun.star.ui.dialogs.OfficeFilePicker"), hat dies keine Auswirkung
auf das Hängenbleiben bei dem MsgBox-Aufruf. Ich spekuliere mal, dass da
wohl vielleicht noch andere ungünstige Randbedingungen auftreten, die
den FilePicker-Fehler kaschieren oder auch der FilePicker-Fehler selbst
andere Fehler verursacht.
[2] Das "neue" Makro
[2.1] Die Dialog-Sachen (Schaltfläche "Start Texte eintragen") habe ich
durch eine einfache InputBox ersetzt.
[2.2] Die Datei "CALC.ods" ist eine unveränderte Kopie Deiner Datei
"Kopfzeilen_Texte.ods".
[2.3] Die Datei "WRITER.odt" ist eine Kopie Deiner Datei "Musterbuch mit
Makro_06.odt", wobei ich lediglich
+ Dein Makro "modKopfzeile" entfernt habe.
+ die Schaltfläche "Start Texte eintragen" entfernt habe.
[2.4] Soweit ich es überschaut habe, liefert mein Makro das gleiche
Ergebnis wie Dein Makro (identische Seitenzahl von 249 Seiten und
entsprechende Kopfzeilen-Einträge, aber auf der letzten Seite (249) gibt
es eine (kleine) Abweichung:
+ Dein Makro: "Mein Text Links 10" und "Mein Text Rechts 10Mein Text
Rechts 10Mein Text Rechts 10"
+ Mein Makro: "Mein Text Links 10" und "Mein Text Rechts 10"
[2.5] Falls Du weitere Abweichungen oder Fehlfunktionen in dem (neuen)
Makro feststellen solltest, so melde Dich bitte.
[3] Hinweise:
[3.1] Makro (Download-Datei: Kopfzeilen.txt)
Das (neue) Makro besteht aus der "Sub Kopfzeilen" und der "Function
DateiAuswahl".
[3.2] Windows-CMD (Download-Datei: Kopfzeilen.cmd)
Damit kann man das Makro (unter Windows) extern starten (für Linux
entsprechend BASH-Syntax):
SET L="C:/Program Files/LibreOffice/program/soffice.exe"
SET M="macro:///Standard.Kopfzeilen.Kopfzeilen()"
%L% --nologo %M%
Mit:
+ Der Speicherpfad von "soffice.exe", muss gegebenenfalls angepasst
werden:
SET L="C:/Program Files/LibreOffice/program/soffice.exe"
+ Der Speicherpfad des Makros:
SET M="macro:///Standard.Kopfzeilen.Kopfzeilen()"
+ Standard = Bibliothek = "[Meine Makros & Dialoge].Standard"
+ Kopfzeilen = Modul = "Kopfzeilen"
+ Kopfzeilen() = Makro (im Modul "Kopfzeilen")
Wenn Du das Makro in der BASIC-IDE nicht in einem Modul abspeicherst,
dann nur: SET M="macro:///Standard.Kopfzeilen()"
[3.3] CALC.ods
Siehe [2.2] !
[3.4] WRITER.odt
Siehe [3.2] !
[3.5] Download-Link
https://www.magentacloud.de/share/r8eyn.v.s0
enthält:
Kopfzeilen.txt
Kopzeilen.cmd
WRITER.odt
CALC.ods
[4] Marko-Code
Dies nur zur Vorschau. Der eMail-Server wird wohl wieder
aufeinanderfolgende Leerzeichen reduzieren, wodurch die Struktur
vermurkst wird. Deshalb besser "Kopfzeilen.txt" anschauen und nutzen,
aber für einen ersten Einblick reicht das schon:
Sub Kopfzeilen
Dim AAM as Integer ' Anzahl Arrayelemente Maximum
Dim ASM as Integer ' Anzahl Seiten Maximum
Dim AFGR as String ' Absatz Formatierung Gerade Rechtsbündig
Dim AFUL as String ' Absatz Formatierung Ungerade Linksbündig
Dim DAC as String ' Datei Art CALC
Dim DAW as String ' Datei Art WRITER
Dim DC as String ' Document CALC: ""=
interaktive Dateiauswahl
'"/'pfad'/'datei'" = keine
ineraktive Dateiauswahl
Dim DF as String ' Dialog Form: "B" = Betriebssystem
' "O" = Office
Dim
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Guten Morgen Gerhard,
ich habe auch mal ein wenig getestet:
[0] Meine Testumgebung
+ Windows 7 Home Premium 64-bit
+ LO 5.3.7.2 (x64) PARALLEL-INSTALLATION
+ LO 6.1.4.2 (x64) PARALLEL-INSTALLATION
+ LO 6.1.5.2 (x64) PARALLEL-INSTALLATION
+ LO 6.2.1.2 (x64) PARALLEL-INSTALLATION
+ LO 6.2.2.2 (x64) INSTALLATION
+ LO 6.2.3.1 (x64) PARALLEL-INSTALLATION
[1] Ich kann bestätigen, dass das Makro von Juergen IMMER fehlerfrei
abläuft, wenn man es direkt aus der BASIC-IDE via "StartKopfzeile"
startet (5.3.7.2 + 6.1.4.1 + 6.1.5.2 + 6.2.1.2 + 6.2.2.2 + 6.2.3.1).
:
Call xSeite
REM
???
REM Einfrieren von LO nach Aktivierung dieser Messagebox
Msgbox "Test"
REM
???
:
[2] Ich kann Juergens Aussage NICHT BESTÄTIGEN, dass sein Makro vor
6.2.1.2 funktionierte ( 5.3.7.2 OKAY + 6.1.4.2 ERROR + 6.1.5.2 ERROR +
6.2.1.2 ERROR + 6.2.2.2 ERROR + 6.2.3.1 ERROR).
[3] Im Laufe dieses Threads wurden 3 (verschiedene) Probleme mitgeteilt:
[3.1] Juergen
Sein BASIC-Makro läuft mit 6.2.1.2 (oder neuer) nicht mehr. Ich kann das
nicht bestätigen, auch mit 6.1.5.2 (s.o.). Bleibt nach dem MsgBox-Aufruf
hängen (soffice.bin mit 25% CPU-Last bei meinen Tests).
[3.2] Hans-Werner
Bei externem Aufruf bleibt nach Anzeige des FolderPicker Betriebssystem
(com.sun.star.ui.dialogs.FolderPicker) und durchgeführter Ordnerauswahl
das BASIC-Makro hängen (soffice.bin mit 0% CPU-Last bei meinen Tests).
Bei Aufruf des Makros direkt aus der BASIC-IDE tritt der Fehler nicht
auf. Mit dem FolderPicker LibreOffice
(com.sun.star.ui.dialogs.OfficeFolderPicker) funktioniert das Makro
fehlerfrei.
[3.3] Oliver
Sein BEANSHELL-Makro bleibt ab LO 6.1.5.2 (oder neuer unter Windows 10)
bei Nutzung des FolderPicker Betriebssystem
(com.sun.star.ui.dialogs.FolderPicker) hängen
(https://bugs.documentfoundation.org/show_bug.cgi?id=123502). Bei
Nutzung des FolderPicker LibreOffice
(com.sun.star.ui.dialogs.OfficeFolderPicker) funktioniert das Makro
fehlerfrei. Sein gemeldetes Problem konnte (von anderen laut BugReport
(nur unter Linux ?) ) nicht reproduziert werden. Mit LO 6.1.4.2 (oder
älter ?) tritt das Problem nicht auf. Wenn ich sein "crash" und "Das
Programm "[1236] soffice.bin" wurde mit Code 0 (0x0) beendet." richtig
deute, heißt das wohl, dass LO komplett abstürzt und LO nicht hängen
bleibt. Es ist auch nicht ersichtlich (bzw. getestet) was passiert, ob
das BEANSHELL-Makro läuft, wenn es aus der BEANSHELL-IDE heraus
gestartet wird, wenn es so eine IDE gibt (habe selbst mit BEANSHELL
keinerlei Erfahrung). Weiterhin merkt Oliver an, das wohl die
FolderPicker-Implementierung modifiziert wurde
(https://bugs.documentfoundation.org/show_bug.cgi?id=123502#c8). Das
konnte ich allerdings nicht nachvollziehen, weil die zugehörige
PDF-Datei
(https://bug-attachments.documentfoundation.org/attachment.cgi?id=149336)
nur sehr unvollständig angezeigt wird.
[4] Von mir mitgeteilte Problematik
[4.1] Makro
Sub TEST_HansWerner
Const FolderPicker = "com.sun.star.ui.dialogs.FolderPicker"
' Const FolderPicker = "com.sun.star.ui.dialogs.OfficeFolderPicker"
Dim DialogFolderPicker as Object
Dim FolderPickerService as String
Dim SelectedFolder as String
Dim PropertyValue(0) as New com.sun.star.beans.PropertyValue
DialogFolderPicker = CreateUnoService(FolderPicker)
DialogFolderPicker.execute()
SelectedFolder = DialogFolderPicker.getDirectory()
MsgBox("SelectedFolder = " & SelectedFolder)
PropertyValue(0).name = "Hidden"
PropertyValue(0).value = False
StarDesktop.loadComponentFromURL("private:factory/scalc","_blank",0,PropertyValue())
MsgBox ("new CALC opened")
End Sub
[4.2] Windows-CMD
SET L="E:/LOP/LibreOffice 6.1.4.2/program/soffice.exe"
SET M="macro:///Standard.Test.TEST_HansWerner()"
%L% --nologo %M%
Mit (SET M="macro:///Standard.Test.TEST_HansWerner()"):
+ "Standard" = Bibliothek = [Meine Makros & Dialoge].Standard
+ "Test" = Modul = Test
+ "TEST_HansWerner()" = Makro = TEST_HansWerner
[4.1] Mit »Const FolderPicker =
"com.sun.star.ui.dialogs.OfficeFolderPicker"« funktioniert das Makro
IMMER, egal, ob extern gestartet (Windows-CMD) oder intern gestartet
(BASIC-IDE).
[4.2] Mit »Const FolderPicker = "com.sun.star.ui.dialogs.FolderPicker"«
funktioniert das Makro immer, wenn es intern gestartet (BASIC-IDE)
gestartet wird.
[4.3] Mit »Const FolderPicker = "com.sun.star.ui.dialogs.FolderPicker"«
funktioniert das Makro nur bis einschließlich "LO 6.1.5.2", wenn es
extern gestartet (Windows-CMD) wird.
[4.4] Mit »Const FolderPicker = "com.sun.star.ui.dialogs.FolderPicker"«
bleibt das Makro ab "LO 6.2.1.2" (einschließlich) hängen, wenn es extern
gestartet (Windows-CMD) wird:
+ soffice.bin: CPU-Last 0%
+ Startet man (manuell) in dieser Situation nochmals "C:\Program
Files\LibreOffice\program\soffice.exe", wird das Makro weiter
(fehlerfrei) ausgeführt.
[5] Zusammenfassung
[5.1] Bei allen
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Gerhard, Am 03.04.2019 um 22:33 schrieb Gerhard Weydt: Ich habe dafür keine Erklärung. Ich habe dann ein neues Writer-Dokument erzeugt, habe die Schaltfläche, den Dialog und den Makro-Code kopiert und eingefügt. Dieses Dokument liefert nun aber keinen Fehler, so dass ich annehmen möchte, dass irgend etwas im Dokument von Jürgen faul ist. Zum Dokument berichte ich wie folgt: Das Originaldokument, des besagten Herrn, für das diese Makro konzipiert ist, ist ein Buch mit ca. 250 Seiten. Das Makro lief einwandfrei. Zu Testzwecken hatte ich zuvor ein leeres Dokument mit mehr als 240 Seiten erstellt. Auch hier gab es anfänglich keinerlei Probleme. Erst nach besagtem LibO-Update und einem Win-Update wurde fror LibO ein. 1. Maßnahme ein gänzlich neue Dokument erstellt und den Code hineinkopiert. Ergebnis LibO friert ein, AOO nicht. 2. LibO Benutzerverzeichnis umbenannt Ergebnis LibO friert ein, AOO nicht. und vieles mehr... Bei einer meiner Tests in den letzten Tagen ist mir dieses aufgefallen: a) Writer mit dem Dokument öffnen b) Basic-IDE öffnen c) Das Programm mit aktivierter abschließender Messagebox starten (egal ob aus dem Dokument oder aus der IDE) d) LibO friert ein e) Taskmanger öffnen ( CPU-Last ca. 25% und sehr hoher Stromverbauch) f) Im Prozesse LibO nur die Basic-IDE killen, in diesem Moment schaltet die Ansicht im TM um auf "Warten auf Benutzer" Dieses hat für mich den Anschein, dass LibO nicht eingefroren ist, sondern die Messagebox den Fokus verloren hat, aber nicht mehr mit Mausklick reaktivierbar ist. Viele Grüße Jürgen -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Gerhard, Am 03.04.2019 um 22:33 schrieb Gerhard Weydt: Frage noch an Jürgen: Warum wird der Dialog erst zur Laufzeit erzeugt, gibt es da einen Grund in dem wahrscheinlich komplizierteren Originaldokument? Ein vorab definierter Dialog ist viel bequemer, man muss sich nicht mit den Listenern befassen. Das Makro habe ich nicht für mich geschrieben, sondern für eine älteren Herrn (>80 J.). Es lief einwandfrei und er hatte es mehrfach in Gebrauch. Dieser hatte schon bei diversen einfacheren Makros Probleme mit der Verwaltung von Makros. Eigene Biblitheken anlegen, was sind Module, etc. Deshalb habe ich alles in einem Modul abgelegt. Ein gezeichnetes Dialogfenster hätte für ihn alles zu sehr verkompliziert. Nun ich hatte auch schon die Listener in Verdacht, zumal ich die Schaltfläche auf dem Dialog per Code geklont habe. Bevor ich das erstemal hier gepostet habe, hatte ich den Code so umgeschrieben, dass nur eine Schaltfläche und ein LIstener aktiv war. Aber auch hier blieb das Programm hängen. Viele Grüße Jürgen -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Jürgen, Hans-Werner, Oliver,
ich habe nun das Problem ziemlich eingrenzen können, kann aber keine
Erklärung für das Verhalten finden.
Aber im Detail:
Ich habe Jürgens Programm reduziert, bis ich zu dem folgenden Rumpf
gekommen bin:
Sub StartKopfzeile
DialogLibraries.LoadLibrary("Standard") 'auch ein fester Dialog
bringt keine Änderung
oDlg = createUnoDialog(DialogLibraries.Standard.Dialog1)
oDlg.execute
End Sub
REM Aktion Pseudo-Kopfzeilen eintragen und formatieren
Sub btnStart_actionPerformed(oEvent2)
sUrl =
converttoUrl("C:\Users\zwi\Musterdateien_02\Kopfzeilen_Texte.ods")
Dim zFileProperties() As New com.sun.star.beans.PropertyValue
' Datei im Hintergrund öffnen
oDocC = StarDesktop.loadComponentFromURL(sURL, "_blank", 0,
zFileProperties())
Xray oDocC
End Sub
Ich habe einen festen Dialog verwendet und auch den Dateinamen fest
eingegeben und das Hidden weggelassen, es war ja sowieso nicht aktiv,
dadurch fällt sehr viel im Code weg.
Das Verhalten ändert sich dadurch nicht, nach dem Xray bleibt LibO
hängen; das scheint bei jeder Art von Dialog zu passieren.
_*Das Wichtige aber:*_ startet man StartKopfzeile statt über die
Schaltfläche direkt aus der Basic-IDE, dann läuft das Programm durch!
Das ist möglicherweise auch der Grund, warum es bei Olivers Test im
Batch geklappt hat.
Ich habe dafür keine Erklärung.
Ich habe dann ein neues Writer-Dokument erzeugt, habe die Schaltfläche,
den Dialog und den Makro-Code kopiert und eingefügt. Dieses Dokument
liefert nun aber keinen Fehler, so dass ich annehmen möchte, dass irgend
etwas im Dokument von Jürgen faul ist.
Das gleiche Vorgehen würde ich Jürgen empfehlen, ob sich jemand findet,
der den wirklichen Grund rauskriegt, halte ich doch für fraglich.
Frage noch an Jürgen: Warum wird der Dialog erst zur Laufzeit erzeugt,
gibt es da einen Grund in dem wahrscheinlich komplizierteren
Originaldokument? Ein vorab definierter Dialog ist viel bequemer, man
muss sich nicht mit den Listenern befassen.
Gruß
Gerhard
Am 02.04.2019 um 20:22 schrieb OoOHWHOoO:
Hallo Oliver,
da fällt mir jetzt nichts mehr dazu ein, außer:
Hast Du das Makro mit "LO 6.2.1.2 (x64)" oder neuer getestet ? Der
Fehler tritt erst ab "LO 6.2.x.x" auf !
Aus Deinem BugReport geht hervor, dass Dein Betriebssystem "Windows
10" ist, meines ist "Windows 7 Home Premium 64-bit". So könnte das
Ganze auch eine "Windows 7"-spezifisches Problem sein, wenn Du das
Makro mit "LO 6.2.1.2 (x64)" oder neuer getestet hast.
Grüße
Hans-Werner
-- Originalnachricht --
Von: "Oliver Brinzing"
An: users@de.libreoffice.org
Gesendet: 02.04.2019 19:02:17
Betreff: Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice
nach Makrodurchlauf
Hallo Hans-Werner,
also ich hab das Makro extern via Batch gestartet - mit und ohne
aktiven Schnellstarter.
Bei mir läuft das durch, hab es mehrfach versucht.
Gruß
Oliver
Am 02.04.2019 um 08:51 schrieb OoOHWHOoO:
Bezug 1: https://listarchives.libreoffice.org/de/users/msg21463.html
Bezug 2: https://listarchives.libreoffice.org/de/users/msg21448.html
Hallo Oliver,
ich habe jetzt mal ganz ausführlich getestet (s.u. TESTREIHE):
[1] Es ist unerheblich, ob man den extern Makro-Aufruf via
"WindowsBatch" oder "Perl" durchführt.
Sollte also auch mit einem (vergleichbaren) Linux-BASH-Aufruf
funktionieren.
[2] Mit der LO-Dateiauswahl
(com.sun.star.ui.dialogs.OfficeFolderPicker) funktioniert das Makro
IMMER FEHLERFREI.
[3] Mit der Betriebssystem-Dateiauswahl
(com.sun.star.ui.dialogs.FolderPicker) funktioniert das
Makro ab "LO 6.2.1.2" NICHT MEHR.
[3.1] Das Makro bleibt hängen, wenn man via angezeigter Dateiauswahl
ein Verzeichnis ausgewählt hat
und danach die Dateiauswahl wieder (automatisch) ausgeblendet wurde.
[3.2] Der WindowsTaskManager zeigt an, dass die Prozesse
"soffice.bin" und "soffice.exe" existieren,
aber keinerlei CPU-Last erzeugen.
[4] Startet man in der Hängenbleiben-Situation [3.1] zusätzlich
manuell "soffice.exe" nochmals,
läuft das Makro dann fehlerfrei weiter.
[4.1] Entgegen meiner früheren Aussage, muss man (beispielsweise)
nicht eine neue CALC manuell
öffnen, es reicht "soffice.exe" manuell (nachzu) starten.
Wie das jetzt alles zusammenhängt ( Warum läuft das Makro weiter,
wenn man "soffice.exe" manuell
nachstartet ?) kann ich nicht erklären, da ich zu wenig über die
LO-internen Abläufe weiß.
Grüße
Hans-Werner
TESTREIHE
(A) LO 5.3.7.2 (x64) - Installation PARALLEL
"com.sun.star.ui.dialogs.FolderPicker" => OKAY
"com.sun.star.ui.dialogs.OfficeFolderPicker" => OKAY
(B) LO 6.1.5.2 (x64) - Installation PARALLEL
"com.sun.star.ui.dialogs.FolderPicker" => OKAY
"com.sun.star.ui.dialogs.OfficeFolderPicker" => O
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo, vielen Dank für Eure vielfältigen Ratschläge, Tests und Eure Zeit. Auch ich war in der Zwischenzeit nicht untätig. Mein Betreibssystem ist Win 10 Pro (x64) 1809 Build (17763.379) Habe nach wie vor Probleme mit den Abstürzen, wenn ich die abschließende Messagebox aktiviere. Auch Verzögerungen durch Wait haben nichts gebracht. Das Makro habe ich nun umgeschrieben und zwei Labels oberhalb der Schaltflächen eingefügt, welche nun den jeweiligen Status farblich und mit Meldungen versehen anzeigen. Dies funktioniert ohne Absturz. Zum Absturz, bzw. Einfrieren habe ich die Windows-Prozesse, bzw. die Libreoffice-Prozesse im Augenblick des Einfrieren genauer unter die Lupe genommen. Zur Analyse von Prozessen habe ich mir vor längerer Zeit das Tool "ProcMon.Exe 3.5" heruntergeladen. Download unter: https://live.sysinternals.com/ <https://live.sysinternals.com/> Mit dem Tool habe ich mir zum Zeitpunkt des Einfrierens eine CSV-Datei mit alle aktiven Prozesses schreiben lassen. Dann habe ich die LibO-Prozesse mittels Calc herausfiltern lassen. Im Anschluß die Duplikate der Spalte "Results" herausgefiltert. Dabei kamen diese Results heraus: SUCCESS REPARSE NAME NOT FOUND FILE LOCKED WITH ONLY READERS NO MORE ENTRIES BUFFER OVERFLOW ACCESS DENIED NO SUCH FILE NAME COLLISION NO MORE FILES PATH NOT FOUND END OF FILE INVALID PARAMETER NOT A DIRECTORY SHARING VIOLATION 0xC4AE FILE LOCKED WITH WRITERS BUFFER TOO SMALL IS DIRECTORY NOT REPARSE POINT FS DRIVER REQUIRED OBJECT PATH INVALID Zu den einzelnen Results, gibt es in der Spalte Path Hinweise zum Ursprung der Meldung. Bei meinen weiteren Überlegungen hatte ich auch meine Firewall und den Virenscanner in Verdacht. Denn zum Zeitpunkt des Absturzes schnellt bekanntlich die CPU-Last auf 25-28% hoch und außerdem wird ein sehr hoher Stromverbrauch gemessen. Da lag die Vermutung nahe, dass die Firewall einen Angriff vermutet. Das hat sich nicht bewahrheitet. Hatte Virenscanner und Firewall abgeschaltet und einen Crash provoziert. Die nächste Überlegung geht in Richtung Betriebssytem. Da ich nach der Erstellung meines ursprüglichen Makros ein WIN-Update von 1803 auf 1809 durchgeführt hatte. Ggf. gibt ist in 1809 irgendwelche neuen Sicherheitsfunktionen, welche Programme mit sehr hohem Stromverbraucxh blocken. Diese ist aber auch nur eine Vermutung. Möchte auch nicht an meinem störungsfrei laufenden Betriebsystem herumbasteln. Die Frage welche sich abschließend stellt, warum kommt es zu einem BUFFER OVERFLOW, BUFFER TOO SMALL, etc. wenn eine Messagebox aufpoppt? Und warum wird ein so hoher Stromverbrauch gemessen? Ach ja, warum dies: NAME COLLISION? Dieses Result wird mir durchgängig bei Prozess soffice.bin in Verbindung mit meinem Windows-User-Pfad bishin zum LibO\4\User angezeigt. Mein Name ohne Umlaut geschrieben: Juergen Nochmals Dank für Alles und an Alle! Viele Grüße Jürgen Am 02.04.2019 um 20:22 schrieb OoOHWHOoO: Hallo Oliver, da fällt mir jetzt nichts mehr dazu ein, außer: Hast Du das Makro mit "LO 6.2.1.2 (x64)" oder neuer getestet ? Der Fehler tritt erst ab "LO 6.2.x.x" auf ! Aus Deinem BugReport geht hervor, dass Dein Betriebssystem "Windows 10" ist, meines ist "Windows 7 Home Premium 64-bit". So könnte das Ganze auch eine "Windows 7"-spezifisches Problem sein, wenn Du das Makro mit "LO 6.2.1.2 (x64)" oder neuer getestet hast. Grüße Hans-Werner -- Originalnachricht -- Von: "Oliver Brinzing" An: users@de.libreoffice.org Gesendet: 02.04.2019 19:02:17 Betreff: Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf Hallo Hans-Werner, also ich hab das Makro extern via Batch gestartet - mit und ohne aktiven Schnellstarter. Bei mir läuft das durch, hab es mehrfach versucht. Gruß Oliver Am 02.04.2019 um 08:51 schrieb OoOHWHOoO: Bezug 1: https://listarchives.libreoffice.org/de/users/msg21463.html Bezug 2: https://listarchives.libreoffice.org/de/users/msg21448.html Hallo Oliver, ich habe jetzt mal ganz ausführlich getestet (s.u. TESTREIHE): [1] Es ist unerheblich, ob man den extern Makro-Aufruf via "WindowsBatch" oder "Perl" durchführt. Sollte also auch mit einem (vergleichbaren) Linux-BASH-Aufruf funktionieren. [2] Mit der LO-Dateiauswahl (com.sun.star.ui.dialogs.OfficeFolderPicker) funktioniert das Makro IMMER FEHLERFREI. [3] Mit der Betriebssystem-Dateiauswahl (com.sun.star.ui.dialogs.FolderPicker) funktioniert das Makro ab "LO 6.2.1.2" NICHT MEHR. [3.1] Das Makro bleibt hängen, wenn man via angezeigter Dateiauswahl ein Verzeichnis ausgewählt hat und danach die Dateiauswahl wieder (automatisch) ausgeblendet wurde. [3.2] Der WindowsTaskManager zeigt an, dass die Prozesse "soffice.bin" und "soffice.exe" existieren, aber keinerlei CPU-Last erzeugen. [4] Startet man in der Hängenbleiben-Situation [3.1] zusätzlich manuell "soffice.exe" nochmal
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Hans-Werner, also ich hab das Makro extern via Batch gestartet - mit und ohne aktiven Schnellstarter. Bei mir läuft das durch, hab es mehrfach versucht. Gruß Oliver Am 02.04.2019 um 08:51 schrieb OoOHWHOoO: Bezug 1: https://listarchives.libreoffice.org/de/users/msg21463.html Bezug 2: https://listarchives.libreoffice.org/de/users/msg21448.html Hallo Oliver, ich habe jetzt mal ganz ausführlich getestet (s.u. TESTREIHE): [1] Es ist unerheblich, ob man den extern Makro-Aufruf via "WindowsBatch" oder "Perl" durchführt. Sollte also auch mit einem (vergleichbaren) Linux-BASH-Aufruf funktionieren. [2] Mit der LO-Dateiauswahl (com.sun.star.ui.dialogs.OfficeFolderPicker) funktioniert das Makro IMMER FEHLERFREI. [3] Mit der Betriebssystem-Dateiauswahl (com.sun.star.ui.dialogs.FolderPicker) funktioniert das Makro ab "LO 6.2.1.2" NICHT MEHR. [3.1] Das Makro bleibt hängen, wenn man via angezeigter Dateiauswahl ein Verzeichnis ausgewählt hat und danach die Dateiauswahl wieder (automatisch) ausgeblendet wurde. [3.2] Der WindowsTaskManager zeigt an, dass die Prozesse "soffice.bin" und "soffice.exe" existieren, aber keinerlei CPU-Last erzeugen. [4] Startet man in der Hängenbleiben-Situation [3.1] zusätzlich manuell "soffice.exe" nochmals, läuft das Makro dann fehlerfrei weiter. [4.1] Entgegen meiner früheren Aussage, muss man (beispielsweise) nicht eine neue CALC manuell öffnen, es reicht "soffice.exe" manuell (nachzu) starten. Wie das jetzt alles zusammenhängt ( Warum läuft das Makro weiter, wenn man "soffice.exe" manuell nachstartet ?) kann ich nicht erklären, da ich zu wenig über die LO-internen Abläufe weiß. Grüße Hans-Werner TESTREIHE (A) LO 5.3.7.2 (x64) - Installation PARALLEL "com.sun.star.ui.dialogs.FolderPicker" => OKAY "com.sun.star.ui.dialogs.OfficeFolderPicker" => OKAY (B) LO 6.1.5.2 (x64) - Installation PARALLEL "com.sun.star.ui.dialogs.FolderPicker" => OKAY "com.sun.star.ui.dialogs.OfficeFolderPicker" => OKAY (C) LO 6.2.1.2 (x64) - Installation PARALLEL "com.sun.star.ui.dialogs.FolderPicker" => ERROR + Makro bleibt hängen. + Startet man in dieser Situation "...\LibreOffice\program\soffice.exe" zusätzlich manuell nach, läuft das Makro fehlerfrei weiter. "com.sun.star.ui.dialogs.OfficeFolderPicker" => OKAY (D) LO 6.2.2.2 (x64) - Installation STANDARD "com.sun.star.ui.dialogs.FolderPicker" => ERROR + Makro bleibt hängen. + Startet man in dieser Situation "...\LibreOffice\program\soffice.exe" zusätzlich manuell nach, läuft das Makro fehlerfrei weiter. "com.sun.star.ui.dialogs.OfficeFolderPicker" => OKAY -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Bezug 1: https://listarchives.libreoffice.org/de/users/msg21463.html Bezug 2: https://listarchives.libreoffice.org/de/users/msg21448.html Hallo Oliver, ich habe jetzt mal ganz ausführlich getestet (s.u. TESTREIHE): [1] Es ist unerheblich, ob man den extern Makro-Aufruf via "WindowsBatch" oder "Perl" durchführt. Sollte also auch mit einem (vergleichbaren) Linux-BASH-Aufruf funktionieren. [2] Mit der LO-Dateiauswahl (com.sun.star.ui.dialogs.OfficeFolderPicker) funktioniert das Makro IMMER FEHLERFREI. [3] Mit der Betriebssystem-Dateiauswahl (com.sun.star.ui.dialogs.FolderPicker) funktioniert das Makro ab "LO 6.2.1.2" NICHT MEHR. [3.1] Das Makro bleibt hängen, wenn man via angezeigter Dateiauswahl ein Verzeichnis ausgewählt hat und danach die Dateiauswahl wieder (automatisch) ausgeblendet wurde. [3.2] Der WindowsTaskManager zeigt an, dass die Prozesse "soffice.bin" und "soffice.exe" existieren, aber keinerlei CPU-Last erzeugen. [4] Startet man in der Hängenbleiben-Situation [3.1] zusätzlich manuell "soffice.exe" nochmals, läuft das Makro dann fehlerfrei weiter. [4.1] Entgegen meiner früheren Aussage, muss man (beispielsweise) nicht eine neue CALC manuell öffnen, es reicht "soffice.exe" manuell (nachzu) starten. Wie das jetzt alles zusammenhängt ( Warum läuft das Makro weiter, wenn man "soffice.exe" manuell nachstartet ?) kann ich nicht erklären, da ich zu wenig über die LO-internen Abläufe weiß. Grüße Hans-Werner TESTREIHE (A) LO 5.3.7.2 (x64) - Installation PARALLEL "com.sun.star.ui.dialogs.FolderPicker" => OKAY "com.sun.star.ui.dialogs.OfficeFolderPicker" => OKAY (B) LO 6.1.5.2 (x64) - Installation PARALLEL "com.sun.star.ui.dialogs.FolderPicker" => OKAY "com.sun.star.ui.dialogs.OfficeFolderPicker" => OKAY (C) LO 6.2.1.2 (x64) - Installation PARALLEL "com.sun.star.ui.dialogs.FolderPicker" => ERROR + Makro bleibt hängen. + Startet man in dieser Situation "...\LibreOffice\program\soffice.exe" zusätzlich manuell nach, läuft das Makro fehlerfrei weiter. "com.sun.star.ui.dialogs.OfficeFolderPicker" => OKAY (D) LO 6.2.2.2 (x64) - Installation STANDARD "com.sun.star.ui.dialogs.FolderPicker" => ERROR + Makro bleibt hängen. + Startet man in dieser Situation "...\LibreOffice\program\soffice.exe" zusätzlich manuell nach, läuft das Makro fehlerfrei weiter. "com.sun.star.ui.dialogs.OfficeFolderPicker" => OKAY -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Oliver,
nur zu Sicherheit:
Du hast das Makro extern gestartet mit einer Aufruf-Variante der Art
via Windows-Batch
SET L="C:/Program Files/LibreOffice/program/soffice.exe"
SET M="macro:///Standard.Test.TEST_FolderPicker()"
%L% --nologo %M%
oder
via Perl
$L = "C:/Program Files/LibreOffice/program/soffice.exe";
$M = "macro:///Standard.Test.TEST_FolderPicker()";
`"$L" --nologo "$M"`;
oder
einem entsprechenden Aufruf in einer Linux-Umgebung ?
Wie ich in meiner Mail erwähnte:
[D] Seit wann dieses Problem genau auftritt kann ich leider nicht sagen,
aber mit "LO 6.2.2.2 (x64) @ Windows 7 Home Premium 64-bit" tritt es
sicher auf.
Ich habe [D] jetzt nochmals getestet und [B] trifft weiterhin zu.
Es kann schon sein, dass der Fehler mit 6.1. noch nicht auftrat, ich
weiß es aber nicht mehr(mit Sicherheit). Aber ich werde mal 6.1.5.2
parallel installieren und testen, es wird nur bis morgen dauern, aber
ich melde mich diesbezüglich auf jeden Fall wieder.
Viele Grüße
Hans-Werner
-- Originalnachricht --
Von: "Oliver Brinzing"
An: users@de.libreoffice.org
Gesendet: 01.04.2019 18:50:16
Betreff: Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice
nach Makrodurchlauf
Hallo Hans-Werner,
ich hab's grad mit LO 6.1.5.2 versucht:
> [B] Wenn man [1.1] extern startet via [1.2] ,
> bleibt das Makro vor dem ERSTEN MsgBox-Aufruf hängen.
> Öffnet man während des Hängenbleibens ein neues CALC-Dokument,
> wird das Makro weiter ausgeführt.
Ich kann das so nicht bestätigen, das Makro läuft bei mir durch.
Gruß
Oliver
Am 31.03.2019 um 19:19 schrieb OoOHWHOoO:
Bezug: https://listarchives.libreoffice.org/de/users/msg21444.html
Hallo Oliver,
ich habe mal bissel was zusammengestellt. Die Makros habe ich so klein wie nur
möglich gehalten
(SourceCodes siehe ganz unten):
[1] FolderPicker (Dateiauswahl via OperatingSystem)
[1.1] Sub TEST_FolderPicker (Makro)
[1.2] TEST_FolderPicker.cmd (externer Makro-Aufruf via WinBatch)
[1.3] TEST_FolderPicker.pl (externer Makro-Aufruf via Perl)
[2] FolderPickerOffice (Dateiauswahl via LibreOffice)
[2.1] Sub TEST_FolderPickerOffice (Makro)
[2.2] TEST_FolderPicker.cmd (externer Makro-Aufruf via WinBatch)
[2.3] TEST_FolderPicker.pl (externer Makro-Aufruf via Perl)
[A] Wenn man [1.1] und [2.1] in der BASIC-IDE (in einem geöffneten
CALC-Dokument) startet,
funktionieren beide Makros fehlerfrei.
[B] Wenn man [1.1] extern startet via [1.2] oder [1.3], bleibt das Makro vor
dem ERSTEN
MsgBox-Aufruf hängen. Öffnet man während des Hängenbleibens ein neues
CALC-Dokument, wird das Makro
weiter ausgeführt.
[C] Wenn man [2.1] extern startet via [2.2] oder [2.3], wird das Makro
fehlerfrei ausgeführt.
[D] Seit wann dieses Problem genau auftritt kann ich leider nicht sagen, aber mit
"LO 6.2.2.2 (x64)
@ Windows 7 Home Premium 64-bit" tritt es sicher auf.
[E] Du kannst die SourceCodes für Deinen BugReport benutzen. Wenn ich es in
Englisch erklärte, wäre
es wohl mehr verwirrend als erklärend ...
[F] Es könnte schon sein, dass diese FolderPicker-Problematik auch ein Hinweis
auf die
FilePicker-Problematik dieses Threads sein könnte, zumindest aber, dass die
Picker-Software nicht
mehr sauber funktioniert, an was auch immer es liegen mag.
Gruß
Hans-Werner
SourceCodes:
[1.1] Sub TEST_FolderPicker (Makro)
Sub TEST_FolderPicker
Const FolderPicker = "com.sun.star.ui.dialogs.FolderPicker"
Dim DialogFolderPicker as Object
Dim FolderPickerService as String
Dim SelectedFolder as String
Dim PropertyValue(0) as New com.sun.star.beans.PropertyValue
DialogFolderPicker = CreateUnoService(FolderPicker)
DialogFolderPicker.execute()
SelectedFolder = DialogFolderPicker.getDirectory()
MsgBox("SelectedFolder = " & SelectedFolder)
PropertyValue(0).name = "Hidden"
PropertyValue(0).value = False
StarDesktop.loadComponentFromURL("private:factory/scalc","_blank",0,PropertyValue())
MsgBox ("new CALC opened")
End Sub
[1.2] TEST_FolderPicker.cmd (externer Makro-Aufruf via WinBatch)
SET L="C:/Program Files/LibreOffice/program/soffice.exe"
SET M="macro:///Standard.Test.TEST_FolderPicker()"
%L% --nologo %M%
[1.3] TEST_FolderPicker.pl (externer Makro-Aufruf via Perl)
$L = "C:/Program Files/LibreOffice/program/soffice.exe";
$M = "macro:///Standard.Test.TEST_FolderPicker()";
`"$L" --nologo "$M"`;
[2.1] Sub TEST_FolderPickerOffice (Makro)
Sub TEST_FolderPickerOffice
Const FolderPicker = "com.sun.star.ui.dialogs.OfficeFolderPicker"
Dim DialogFolderPicker as Object
Dim FolderPickerService as String
Dim SelectedFolder as String
Dim PropertyValue(0) as New com.sun.star.beans.PropertyValue
DialogFolderPicker = CreateUnoService(FolderPicker)
DialogFolderPicker.execute()
SelectedFolder = DialogFolderPicker.getDirectory()
MsgBox("SelectedFolder = "
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Hans-Werner,
ich hab's grad mit LO 6.1.5.2 versucht:
> [B] Wenn man [1.1] extern startet via [1.2] ,
> bleibt das Makro vor dem ERSTEN MsgBox-Aufruf hängen.
> Öffnet man während des Hängenbleibens ein neues CALC-Dokument,
> wird das Makro weiter ausgeführt.
Ich kann das so nicht bestätigen, das Makro läuft bei mir durch.
Gruß
Oliver
Am 31.03.2019 um 19:19 schrieb OoOHWHOoO:
Bezug: https://listarchives.libreoffice.org/de/users/msg21444.html
Hallo Oliver,
ich habe mal bissel was zusammengestellt. Die Makros habe ich so klein wie nur
möglich gehalten
(SourceCodes siehe ganz unten):
[1] FolderPicker (Dateiauswahl via OperatingSystem)
[1.1] Sub TEST_FolderPicker (Makro)
[1.2] TEST_FolderPicker.cmd (externer Makro-Aufruf via WinBatch)
[1.3] TEST_FolderPicker.pl (externer Makro-Aufruf via Perl)
[2] FolderPickerOffice (Dateiauswahl via LibreOffice)
[2.1] Sub TEST_FolderPickerOffice (Makro)
[2.2] TEST_FolderPicker.cmd (externer Makro-Aufruf via WinBatch)
[2.3] TEST_FolderPicker.pl (externer Makro-Aufruf via Perl)
[A] Wenn man [1.1] und [2.1] in der BASIC-IDE (in einem geöffneten
CALC-Dokument) startet,
funktionieren beide Makros fehlerfrei.
[B] Wenn man [1.1] extern startet via [1.2] oder [1.3], bleibt das Makro vor
dem ERSTEN
MsgBox-Aufruf hängen. Öffnet man während des Hängenbleibens ein neues
CALC-Dokument, wird das Makro
weiter ausgeführt.
[C] Wenn man [2.1] extern startet via [2.2] oder [2.3], wird das Makro
fehlerfrei ausgeführt.
[D] Seit wann dieses Problem genau auftritt kann ich leider nicht sagen, aber mit
"LO 6.2.2.2 (x64)
@ Windows 7 Home Premium 64-bit" tritt es sicher auf.
[E] Du kannst die SourceCodes für Deinen BugReport benutzen. Wenn ich es in
Englisch erklärte, wäre
es wohl mehr verwirrend als erklärend ...
[F] Es könnte schon sein, dass diese FolderPicker-Problematik auch ein Hinweis
auf die
FilePicker-Problematik dieses Threads sein könnte, zumindest aber, dass die
Picker-Software nicht
mehr sauber funktioniert, an was auch immer es liegen mag.
Gruß
Hans-Werner
SourceCodes:
[1.1] Sub TEST_FolderPicker (Makro)
Sub TEST_FolderPicker
Const FolderPicker = "com.sun.star.ui.dialogs.FolderPicker"
Dim DialogFolderPicker as Object
Dim FolderPickerService as String
Dim SelectedFolder as String
Dim PropertyValue(0) as New com.sun.star.beans.PropertyValue
DialogFolderPicker = CreateUnoService(FolderPicker)
DialogFolderPicker.execute()
SelectedFolder = DialogFolderPicker.getDirectory()
MsgBox("SelectedFolder = " & SelectedFolder)
PropertyValue(0).name = "Hidden"
PropertyValue(0).value = False
StarDesktop.loadComponentFromURL("private:factory/scalc","_blank",0,PropertyValue())
MsgBox ("new CALC opened")
End Sub
[1.2] TEST_FolderPicker.cmd (externer Makro-Aufruf via WinBatch)
SET L="C:/Program Files/LibreOffice/program/soffice.exe"
SET M="macro:///Standard.Test.TEST_FolderPicker()"
%L% --nologo %M%
[1.3] TEST_FolderPicker.pl (externer Makro-Aufruf via Perl)
$L = "C:/Program Files/LibreOffice/program/soffice.exe";
$M = "macro:///Standard.Test.TEST_FolderPicker()";
`"$L" --nologo "$M"`;
[2.1] Sub TEST_FolderPickerOffice (Makro)
Sub TEST_FolderPickerOffice
Const FolderPicker = "com.sun.star.ui.dialogs.OfficeFolderPicker"
Dim DialogFolderPicker as Object
Dim FolderPickerService as String
Dim SelectedFolder as String
Dim PropertyValue(0) as New com.sun.star.beans.PropertyValue
DialogFolderPicker = CreateUnoService(FolderPicker)
DialogFolderPicker.execute()
SelectedFolder = DialogFolderPicker.getDirectory()
MsgBox("SelectedFolder = " & SelectedFolder)
PropertyValue(0).name = "Hidden"
PropertyValue(0).value = False
StarDesktop.loadComponentFromURL("private:factory/scalc","_blank",0,PropertyValue())
MsgBox ("new CALC opened")
End Sub
[2.2] TEST_FolderPicker.cmd (externer Makro-Aufruf via WinBatch)
SET L="C:/Program Files/LibreOffice/program/soffice.exe"
SET M="macro:///Standard.Test.TEST_FolderPickerOffice()"
%L% --nologo %M%
[2.3] TEST_FolderPicker.pl (externer Makro-Aufruf via Perl)
$L = "C:/Program Files/LibreOffice/program/soffice.exe";
$M = "macro:///Standard.Test.TEST_FolderPickerOffice()";
`"$L" --nologo "$M"`;
--
Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org
Probleme?
https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/users/
Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Bezug: https://listarchives.libreoffice.org/de/users/msg21448.html Da ist mir leider ein Kopierfehler unterlaufen :-0 ... Falsch: [2.2] TEST_FolderPicker.cmd (externer Makro-Aufruf via WinBatch) [2.3] TEST_FolderPicker.pl (externer Makro-Aufruf via Perl) Richtig: [2.2] TEST_FolderPickerOffice.cmd (externer Makro-Aufruf via WinBatch) [2.3] TEST_FolderPickerOffice.pl (externer Makro-Aufruf via Perl) Gruß Hans-Werner -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Bezug: https://listarchives.libreoffice.org/de/users/msg21444.html
Hallo Oliver,
ich habe mal bissel was zusammengestellt. Die Makros habe ich so klein
wie nur möglich gehalten (SourceCodes siehe ganz unten):
[1] FolderPicker (Dateiauswahl via OperatingSystem)
[1.1] Sub TEST_FolderPicker (Makro)
[1.2] TEST_FolderPicker.cmd (externer Makro-Aufruf via WinBatch)
[1.3] TEST_FolderPicker.pl (externer Makro-Aufruf via Perl)
[2] FolderPickerOffice (Dateiauswahl via LibreOffice)
[2.1] Sub TEST_FolderPickerOffice (Makro)
[2.2] TEST_FolderPicker.cmd (externer Makro-Aufruf via WinBatch)
[2.3] TEST_FolderPicker.pl (externer Makro-Aufruf via Perl)
[A] Wenn man [1.1] und [2.1] in der BASIC-IDE (in einem geöffneten
CALC-Dokument) startet, funktionieren beide Makros fehlerfrei.
[B] Wenn man [1.1] extern startet via [1.2] oder [1.3], bleibt das Makro
vor dem ERSTEN MsgBox-Aufruf hängen. Öffnet man während des
Hängenbleibens ein neues CALC-Dokument, wird das Makro weiter
ausgeführt.
[C] Wenn man [2.1] extern startet via [2.2] oder [2.3], wird das Makro
fehlerfrei ausgeführt.
[D] Seit wann dieses Problem genau auftritt kann ich leider nicht sagen,
aber mit "LO 6.2.2.2 (x64) @ Windows 7 Home Premium 64-bit" tritt es
sicher auf.
[E] Du kannst die SourceCodes für Deinen BugReport benutzen. Wenn ich es
in Englisch erklärte, wäre es wohl mehr verwirrend als erklärend ...
[F] Es könnte schon sein, dass diese FolderPicker-Problematik auch ein
Hinweis auf die FilePicker-Problematik dieses Threads sein könnte,
zumindest aber, dass die Picker-Software nicht mehr sauber funktioniert,
an was auch immer es liegen mag.
Gruß
Hans-Werner
SourceCodes:
[1.1] Sub TEST_FolderPicker (Makro)
Sub TEST_FolderPicker
Const FolderPicker = "com.sun.star.ui.dialogs.FolderPicker"
Dim DialogFolderPicker as Object
Dim FolderPickerService as String
Dim SelectedFolder as String
Dim PropertyValue(0) as New com.sun.star.beans.PropertyValue
DialogFolderPicker = CreateUnoService(FolderPicker)
DialogFolderPicker.execute()
SelectedFolder = DialogFolderPicker.getDirectory()
MsgBox("SelectedFolder = " & SelectedFolder)
PropertyValue(0).name = "Hidden"
PropertyValue(0).value = False
StarDesktop.loadComponentFromURL("private:factory/scalc","_blank",0,PropertyValue())
MsgBox ("new CALC opened")
End Sub
[1.2] TEST_FolderPicker.cmd (externer Makro-Aufruf via WinBatch)
SET L="C:/Program Files/LibreOffice/program/soffice.exe"
SET M="macro:///Standard.Test.TEST_FolderPicker()"
%L% --nologo %M%
[1.3] TEST_FolderPicker.pl (externer Makro-Aufruf via Perl)
$L = "C:/Program Files/LibreOffice/program/soffice.exe";
$M = "macro:///Standard.Test.TEST_FolderPicker()";
`"$L" --nologo "$M"`;
[2.1] Sub TEST_FolderPickerOffice (Makro)
Sub TEST_FolderPickerOffice
Const FolderPicker = "com.sun.star.ui.dialogs.OfficeFolderPicker"
Dim DialogFolderPicker as Object
Dim FolderPickerService as String
Dim SelectedFolder as String
Dim PropertyValue(0) as New com.sun.star.beans.PropertyValue
DialogFolderPicker = CreateUnoService(FolderPicker)
DialogFolderPicker.execute()
SelectedFolder = DialogFolderPicker.getDirectory()
MsgBox("SelectedFolder = " & SelectedFolder)
PropertyValue(0).name = "Hidden"
PropertyValue(0).value = False
StarDesktop.loadComponentFromURL("private:factory/scalc","_blank",0,PropertyValue())
MsgBox ("new CALC opened")
End Sub
[2.2] TEST_FolderPicker.cmd (externer Makro-Aufruf via WinBatch)
SET L="C:/Program Files/LibreOffice/program/soffice.exe"
SET M="macro:///Standard.Test.TEST_FolderPickerOffice()"
%L% --nologo %M%
[2.3] TEST_FolderPicker.pl (externer Makro-Aufruf via Perl)
$L = "C:/Program Files/LibreOffice/program/soffice.exe";
$M = "macro:///Standard.Test.TEST_FolderPickerOffice()";
`"$L" --nologo "$M"`;
--
Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org
Probleme?
https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/users/
Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Robert, ich habe es eben nochmals (schnell) getestet (LO 6.2.2.2 (x64) @ Windows 7 Home Premium 64-bit) [1] com.sun.star.ui.dialogs.FolderPicker MAKRO bleibt hängen vor/am folgenden MsgBox-Aufruf. ABER: Wenn ich während dieses Hängenbleibens eine neue CALC-Datei öffne, läuft das MAKRO fehlerfrei weiter. [2] com.sun.star.ui.dialogs.OfficeFolderPicker => MAKRO läuft fehlerfrei. Gruß Hans-Werner -- Originalnachricht -- Von: "Robert Großkopf" An: users@de.libreoffice.org Gesendet: 31.03.2019 15:00:05 Betreff: Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf Hallo *, Ich selbst habe bei einem MAKRO im Kontext mit dem Öffnen einer CALC-Datei das Problem, wenn ich den "Folder Picker Betriebs System" auswähle, dass das MAKRO einfriert, nicht aber, wenn ich den "Folder Picker Open Office" auswähle. Nicht aber bei früheren LO-Versionen. Vielleicht besteht ja ein Zusammenhang zu obigem Problem, dass die BASIC-MAKRO-Picker nicht mehr 100%ig funktionieren, ist aber nur eine vage Vermutung: ' Folder Picker Betriebs System: Const FPBS = "com.sun.star.ui.dialogs.FolderPicker" ' Folder Picker Open Office: Const FPOO = "com.sun.star.ui.dialogs.OfficeFolderPicker" Ist nicht seit den Versionen LO 6.0 der interne Dialog ganz verschwunden? Oder hat das nichts mit der GUI zu tun. Wählbar ist da jedenfalls nicht mehr in der grafischen benutzeroberfläche. Es wird immer der Dialog des Betriebssystems genommen. Gruß Robert -- Homepage: http://robert.familiegrosskopf.de LibreOffice Community: http://robert.familiegrosskopf.de/map_3 -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Robert, ' Folder Picker Betriebs System: Const FPBS = "com.sun.star.ui.dialogs.FolderPicker" ' Folder Picker Open Office: Const FPOO = "com.sun.star.ui.dialogs.OfficeFolderPicker" Ist nicht seit den Versionen LO 6.0 der interne Dialog ganz verschwunden? Oder hat das nichts mit der GUI zu tun. Wählbar ist da jedenfalls nicht mehr in der grafischen benutzeroberfläche. Es wird immer der Dialog des Betriebssystems genommen. Du kannst ihn über die API direkt instanzieren, bzw. in in den Experteneinstellungen auch generell freischalten: Menü Extras/Optionen.../LibreOffice/Erweitert -> [Experteneinstellungen] Suche nach: UseSystemFileDialog Gruß Oliver -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo *, > Ich selbst habe bei einem MAKRO im Kontext mit dem Öffnen einer > CALC-Datei das Problem, wenn ich den "Folder Picker Betriebs System" > auswähle, dass das MAKRO einfriert, nicht aber, wenn ich den "Folder > Picker Open Office" auswähle. Nicht aber bei früheren LO-Versionen. > Vielleicht besteht ja ein Zusammenhang zu obigem Problem, dass die > BASIC-MAKRO-Picker nicht mehr 100%ig funktionieren, ist aber nur eine > vage Vermutung: > > ' Folder Picker Betriebs System: > Const FPBS = "com.sun.star.ui.dialogs.FolderPicker" > ' Folder Picker Open Office: > Const FPOO = "com.sun.star.ui.dialogs.OfficeFolderPicker" Ist nicht seit den Versionen LO 6.0 der interne Dialog ganz verschwunden? Oder hat das nichts mit der GUI zu tun. Wählbar ist da jedenfalls nicht mehr in der grafischen benutzeroberfläche. Es wird immer der Dialog des Betriebssystems genommen. Gruß Robert -- Homepage: http://robert.familiegrosskopf.de LibreOffice Community: http://robert.familiegrosskopf.de/map_3 -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo,
> ANMERKUNG:
> Ich selbst habe bei einem MAKRO im Kontext mit dem Öffnen einer CALC-Datei
das Problem, wenn ich
> den "Folder Picker Betriebs System" auswähle, dass das MAKRO einfriert,
nicht aber, wenn ich den
> "Folder Picker Open Office" auswähle. Nicht aber bei früheren LO-Versionen.
Vielleicht besteht ja
> ein Zusammenhang zu obigem Problem, dass die BASIC-MAKRO-Picker nicht mehr
100%ig funktionieren, ist
> aber nur eine vage Vermutung:
> ' Folder Picker Betriebs System:
> Const FPBS = "com.sun.star.ui.dialogs.FolderPicker"
> ' Folder Picker Open Office:
> Const FPOO = "com.sun.star.ui.dialogs.OfficeFolderPicker"
Das Problem habe ich auch, es tritt seit Version 6.1 auf, vgl.:
Bug 123502 - crash: use of "com.sun.star.ui.dialogs.FolderPicker" service from
java seems to cause
crashes since LO 6.1
https://bugs.documentfoundation.org/show_bug.cgi?id=123502
Irgendetwas stimmt mit dem System-Folder Picker nicht mehr..
Wenn Du ein ein einfaches Basic Makro Demo hast, füge es bitte dem issue bei.
Gruß
Oliver
Am 31.03.2019 um 12:15 schrieb OoOHWHOoO:
Hallo,
ich habe diesbezüglich auch mal ein wenig getestet:
[1] Mit "Hidden" und "False" friert LO bei "MsgBox ("FileOperation: NACH
StarDesktop.loadComponentFromURL")" ein (s.u.).
[2] Mit "Hidden" und "True" friert LO bei "MsgBox ("NACH FileOperation")" ein
(s.u.).
In beiden Fällen hat "soffice.bin" eine CPU-Auslastung von zirka 25%.
Bei diesen Zeilen ( > ) habe ich das Makro modifiziert (s.u.).
Testumgebung: LO 6.2.2.2 (x64) @ Windows 7 Home Premium 64-bit.
Eine Erklärung für das oben geschilderte Verhalten habe ich leider nicht.
ANMERKUNG:
Ich selbst habe bei einem MAKRO im Kontext mit dem Öffnen einer CALC-Datei das
Problem, wenn ich
den "Folder Picker Betriebs System" auswähle, dass das MAKRO einfriert, nicht
aber, wenn ich den
"Folder Picker Open Office" auswähle. Nicht aber bei früheren LO-Versionen.
Vielleicht besteht ja
ein Zusammenhang zu obigem Problem, dass die BASIC-MAKRO-Picker nicht mehr
100%ig funktionieren, ist
aber nur eine vage Vermutung:
' Folder Picker Betriebs System:
Const FPBS = "com.sun.star.ui.dialogs.FolderPicker"
' Folder Picker Open Office:
Const FPOO = "com.sun.star.ui.dialogs.OfficeFolderPicker"
Grüße
Hans-Werner :-))
[3] Makro-Modifikationen
Option Explicit
> Private oDlgM as Object ' das Modell des Dialogs
> Private oDlg as Object ' Dialogfenster
> Private oMod as Object ' nimmt jeweils das Modell der Objekte
auf (Textfeld)
> Private oMod1 as Object ' nimmt jeweils das Modell der Objekte
auf (Button)
> Private oMod2 as Object ' nimmt jeweils das Modell der Objekte
auf (Button)
> Private oMod3 as Object ' nimmt jeweils das Modell der Objekte
auf (Button)
> Private oWin as Object
> Private oListener1 as Object
> Private oListener2 as Object
> Private oListener3 as Object
> Private oControl1 as Object
> Private oControl2 as Object
> Private oControl3 as Object
REM Deklaration der Variablen
> Private oDocW as Object ' Writer-Dokument
> Private oDocC as Object ' Calc-Dokument (wird versteckt
geöffnet)
:
:
Sub Dateidialog
On Error GoTo ErrorHandler
MsgBox "Der nachfolgende Dateidialog fordert sie zum Öffnen dieser Datei auf:"
& chr(10) & _
">>> Kopfzeilen_Texte.ods <<<" & chr(10) & _
"Wählen Sie zunächst den korrekten Pfad zu dieser Datei aus."
,64,"Hinweis"
' Filepicker (Datei-Dialog)
sUrl = FileOpenDialog ("Bitte wählen Sie eine Calc-Datei aus!")
if sURL = "" then
Msgbox "Sie haben den Dateidialog abgebrochen!" & chr(10) & _
"Starten Sie das Programm erneut und wählen eine Calc-Datei
aus!", 48, "Fehler:
Anwender hat Dateiauswahl abgebrochen!"
exit sub
end if
sExt=getFileNameExtension(sURL)
' Fehlermeldung für den Fall, dass kein Calc-Dokument ausgewählt
wurde
if sExt <> "ods" then
MsgBox("Bitte wählen Sie ein Calc-Dokument aus!" & chr(10) & _
"Das Programm wird beendet!" & chr(10) & chr(10)
& _
"Starten Sie das Programm erneut.", 48, "Fehler:
Dateiauswahl")
exit sub
end if
REM Calc-Datei im Hintergrund öffnen
> MsgBox ("VOR FileOperation")
FileOperation
> MsgBox ("NACH FileOperation")
' MsgBox "Error " & Err & ": " & Error$ & " (line : " & Erl & ")"
'oCC.getFrame().getContainerWindow().setVisible(True)
Exit Sub
REM ErrorHandler für den Fall, dass im Dateidialog auf "ABRUCH" geklickt wurde
ErrorHandler:
'MsgBox "Error " & Err & ": " & Error$ & " (line : " & Erl & ")"
Msgbox "Sie haben den Dateidialog abgebrochen!" & chr(10) & _
"Starten Sie das Programm erneut und
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo,
ich habe diesbezüglich auch mal ein wenig getestet:
[1] Mit "Hidden" und "False" friert LO bei "MsgBox ("FileOperation: NACH
StarDesktop.loadComponentFromURL")" ein (s.u.).
[2] Mit "Hidden" und "True" friert LO bei "MsgBox ("NACH
FileOperation")" ein (s.u.).
In beiden Fällen hat "soffice.bin" eine CPU-Auslastung von zirka 25%.
Bei diesen Zeilen ( > ) habe ich das Makro modifiziert (s.u.).
Testumgebung: LO 6.2.2.2 (x64) @ Windows 7 Home Premium 64-bit.
Eine Erklärung für das oben geschilderte Verhalten habe ich leider
nicht.
ANMERKUNG:
Ich selbst habe bei einem MAKRO im Kontext mit dem Öffnen einer
CALC-Datei das Problem, wenn ich den "Folder Picker Betriebs System"
auswähle, dass das MAKRO einfriert, nicht aber, wenn ich den "Folder
Picker Open Office" auswähle. Nicht aber bei früheren LO-Versionen.
Vielleicht besteht ja ein Zusammenhang zu obigem Problem, dass die
BASIC-MAKRO-Picker nicht mehr 100%ig funktionieren, ist aber nur eine
vage Vermutung:
' Folder Picker Betriebs System:
Const FPBS = "com.sun.star.ui.dialogs.FolderPicker"
' Folder Picker Open Office:
Const FPOO = "com.sun.star.ui.dialogs.OfficeFolderPicker"
Grüße
Hans-Werner :-))
[3] Makro-Modifikationen
Option Explicit
> Private oDlgM as Object ' das Modell des Dialogs
> Private oDlg as Object ' Dialogfenster
> Private oMod as Object ' nimmt jeweils das Modell der
Objekte auf(Textfeld)
> Private oMod1 as Object ' nimmt jeweils das Modell der
Objekte auf(Button)
> Private oMod2 as Object ' nimmt jeweils das Modell der
Objekte auf(Button)
> Private oMod3 as Object ' nimmt jeweils das Modell der
Objekte auf(Button)
> Private oWin as Object
> Private oListener1 as Object
> Private oListener2 as Object
> Private oListener3 as Object
> Private oControl1 as Object
> Private oControl2 as Object
> Private oControl3 as Object
REM Deklaration der Variablen
> Private oDocW as Object' Writer-Dokument
> Private oDocC as Object' Calc-Dokument (wird
versteckt geöffnet)
:
:
Sub Dateidialog
On Error GoTo ErrorHandler
MsgBox "Der nachfolgende Dateidialog fordert sie zum Öffnen
dieser Datei auf:" & chr(10) & _
">>> Kopfzeilen_Texte.ods <<<" & chr(10) & _
"Wählen Sie zunächst den korrekten Pfad zu dieser
Datei aus." ,64,"Hinweis"
' Filepicker (Datei-Dialog)
sUrl = FileOpenDialog ("Bitte wählen Sie eine Calc-Datei aus!")
if sURL = "" then
Msgbox "Sie haben den Dateidialog abgebrochen!" &
chr(10) & _
"Starten Sie das Programm erneut und wählen eine
Calc-Datei aus!", 48, "Fehler: Anwender hat Dateiauswahl abgebrochen!"
exit sub
end if
sExt=getFileNameExtension(sURL)
' Fehlermeldung für den Fall, dass kein Calc-Dokument
ausgewählt wurde
if sExt <> "ods" then
MsgBox("Bitte wählen Sie ein Calc-Dokument aus!" &
chr(10) & _
"Das Programm wird beendet!" & chr(10) &
chr(10) & _
"Starten Sie das Programm erneut.", 48,
"Fehler: Dateiauswahl")
exit sub
end if
REM Calc-Datei im Hintergrund öffnen
> MsgBox ("VOR FileOperation")
FileOperation
> MsgBox ("NACH FileOperation")
' MsgBox "Error " & Err & ": " & Error$ & " (line : " & Erl & ")"
'oCC.getFrame().getContainerWindow().setVisible(True)
Exit Sub
REM ErrorHandler für den Fall, dass im Dateidialog auf "ABRUCH" geklickt
wurde
ErrorHandler:
'MsgBox "Error " & Err & ": " & Error$ & " (line : " & Erl & ")"
Msgbox "Sie haben den Dateidialog abgebrochen!" & chr(10) & _
"Starten Sie das Programm erneut und wählen eine Calc-Datei
aus!", 48, "Fehler: Anwender hat Dateiauswahl abgebrochen!"
End Sub
REM
REM Calc-Datei im Hintergrund öffnen
REM Dateioperation: Datei öffnen und auslesen
Sub FileOperation
'oCC.getFrame().getContainerWindow().setVisible(False)
' Eigenschaften
> Dim myFileProperties(0) As New com.sun.star.beans.PropertyValue
' Dokument im Hintergrund öffnen
>myFileProperties(0).Name = "Hidden"
>myFileProperties(0).Value = False
REM
---
' Datei im Hintergrund öffnen
> MsgBox ("FileOperation: VOR StarDesktop.loadComponentFromURL")
> sURL = ConvertToURL(sURL)
> oDocC = StarDesktop.loadComponentFromURL(sURL, "_blank", 0,
myFileProperties())
> MsgBox ("FileOperation: NACH StarDesktop.loadComponentFromURL")
'mri oDocC
' Daten aus Tabelle einlesen und in die Arrays verteilen
'
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Jürgen, Am 30.03.2019 um 19:33 schrieb Jürgen Klatt: Hallo Thomas, habe nun meinen Code entsprechend Deines Ratschlags und diverser anderer Ungereimtheiten überarbeitet. Schon mal gut :) 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 -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
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 Am 30.03.2019 um 19:33 schrieb Jürgen Klatt: 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 Am 28.03.2019 um 21:45 schrieb Jürgen Klatt: 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 Am 28.03.2019 um 20:58 schrieb Thomas Krumbein: Hallo Jürgen, Am 28.03.2019 um 20:14 schrieb Jürgen Klatt: ... 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 -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
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 Am 28.03.2019 um 21:45 schrieb Jürgen Klatt: 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 Am 28.03.2019 um 20:58 schrieb Thomas Krumbein: Hallo Jürgen, Am 28.03.2019 um 20:14 schrieb Jürgen Klatt: ... 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 -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
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 Am 28.03.2019 um 20:58 schrieb Thomas Krumbein: Hallo Jürgen, Am 28.03.2019 um 20:14 schrieb Jürgen Klatt: ... 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 -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Versionsabhängiges Einfrieren von LibreOffice nach Makrodurchlauf
Hallo Jürgen, Am 28.03.2019 um 20:14 schrieb Jürgen Klatt: ... 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 -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
