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" <gerhard.weydt@t-online.de>
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 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" <jrk33@web.de>
> > 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+unsubscribe@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+unsubscribe@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+unsubscribe@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