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" <[email protected]>
An: [email protected]
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" => 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: [email protected]
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: [email protected]
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
