BASIC-Makro @ CALC - Cursor-Positionierung

de-users
#1

Hallo Thomas,

ich habe jetzt mal folgende Tests Durchgeführt:

[1] Das Systemabbild vom 30.07.2018 zurück eingespielt.

[2] Mit dem zurück eingespielten Systemabbild steht nun wieder die alte LO-Version mit Download- und Installationsdatum 05.11.2017 zur Verfügung:

Version: 5.3.7.2 (x64)
Build-ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059
CPU-Threads: 4; BS-Version: Windows 6.1; UI-Render: Standard; Layout-Engine: neu;
Gebietsschema: de-DE (de_DE); Calc: group

[3] Ausführung des Makros (siehe [12]) mit aus-kommentierter Zeile »oTB.getCellByPosition(0,0).String = "Cursor"«. Alles bestens. Die Spalten werden NICHT nach links weg geschoben. Alle 5 Spalten sind sichtbar.

[4] Anschließend habe ich LO beendet, mein LO-Benutzerprofil an einen anderen Ort verschoben und LO wieder gestartet. LO hat erwartungsgemäß eine neues Benutzerprofil angelegt.

[5] JETZT ABER: Ausführung des Makros (s.u.) mit oder ohne aus-kommentierter Zeile »oTB.getCellByPosition(0,0).String = "Cursor"«. Der Fehler tritt in beiden Fällen auf. Die Spalten werden nach links verschoben, so dass links oben in der Ecke die Zelle "E1" angezeigt wird.

[7] Anschließend habe ich jetzt noch mit der "Separate Install GUI" LO "5.3.7.2 (x64)" parallel installiert. Es ist exakt die selbe LO-Version wie die des standardmäßig installierten LO (siehe [2]), aber eben ohne "mein" LO-Benutzerverzeichnis.

Version: 5.3.7.2 (x64)
Build-ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059
CPU-Threads: 4; BS-Version: Windows 6.1; UI-Render: Standard; Layout-Engine: neu;
Gebietsschema: de-DE (de_DE); Calc: CL

[8] Genau der selbe Fehler wie unter [5] beschrieben.

[9] Anschließend habe ich das neue LO installiert - unter Beibehaltung meines (alten) standardmäßigen Benutzerprofils:

Version: 6.0.6.2 (x64)
Build-ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77
CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard;
Gebietsschema: de-DE (de_DE); Calc: group

[10] Fehlerfreie Ausführung des Makros wie unter [3].

[1] Vorläufige Folgerungen

[11.1] Der Fehler tritt NUR DANN NICHT auf, wenn das standardmäßige (alte) LO-Benutzerprofils zum Tragen kommt. In allen anderen Fällen - "neu angelegtes Benutzerprofil" oder "Benutzerprofil der Parallelinstallation" - tritt der Fehler auf. Eine Abhängigkeit von der genutzten LO-Version ist nicht ersichtlich.

[11.2] Wenn Du Dein Benutzerprofil von LO neu anlegen lässt, solltest Du den Fehler reproduzieren können.

[11.3] Ich habe keinen Schimmer, wo da das Problem mit den von LO neu angelegten Benutzerprofilen liegen könnte.

[12] Test-Makro

Sub SetCursor_loadComponent

Dim oD as Object
Dim oTB as Object
Dim aB() as String
Dim X as Integer

aB = Array("A","B","C","D","E")

Const P1 = "private:factory/scalc"
Const P2 = "_blank"
Const P3 = 0
Dim aPV(0) as New com.sun.star.beans.PropertyValue
aPV(0).name = "Hidden"
aPV(0).value = True

oD = StarDesktop.loadComponentFromURL(P1,P2,P3,aPV())
oTB = oD.sheets(0)
For X=0 To UBound(aB) Step 1
oTB.getCellByPosition(X,0).String = aB(X)
Next X
' oTB.getCellByPosition(0,0).String = "Cursor" ' Kommentiert, weil nicht wirklich notwendig !
oD.getCurrentController().getFrame().getContainerWindow().setVisible(True)
oD.CurrentController.Select(oTB.getCellByPosition(4,0))

End Sub

Gruß
Hans-Werner ;-))

#2

Hallo Hans-Werner,

nun war ich doch neugierig und hab das mal getestet mit ner frischen 6.1 - und ja, Ich kann Dein Verhalten bestätigen.

Also mal tiefer "analysiert" - und alles sieht gut aus.

Ich denke, es ist einfach ein Timing-Problem. Betrachte ich mir im Objektinspektor die Inhalte der aktuellen Zelle etc... passt alles.

ich denke, die Anweisung

oD.CurrentController.Select(oTB.getCellByPosition(4,0))

wird einfach schon ausgeführt, bevor die Visibility fertig gestellt ist - ud schwupp ist eben die Zelle (4,0) die erste sichtbare.

Hab einfach eine wait-Anweisung ergänzt und alles läuft wie gewünscht.

...

oD.getCurrentController().getFrame().getContainerWindow().setVisible(True)
wait(500)
oD.CurrentController.Select(oTB.getCellByPosition(4,0))
...

Vielleicht reicht Dir das ja...

VG
Thomas

#3

Hallo Thomas,

erst mal ein herzliches Danke für Deine Untersuchungen, Analysen und Ergebnisse :-)) !!!

Aber was ich absolut nicht verstehe, was hat das Ganze mit dem Benutzerprofil zu tun ?

Mit meinem alten Benutzerprofil funktioniert es (unabhängig von den LO Versionen) und mit einem neu angelegten Benutzerprofil tritt der Fehler auf (unabhängig von den LO Versionen). Wie kann das Benutzerprofil (unterschwellig) auf dieses Timing Einfluss nehmen ? Das "schnüffelt" für mich schon ein wenig nach BUG ... oder habe ich da etwas in Deinen Ausführungen völlig falsch verstanden ?

Ich habe jetzt mal Deinen "Wait(500)"-Vorschlag mit meinen Parallel-Installationen [ 5.3.7.2 (x64) + 6.1.0.3 (x64) ] - die ja das von "Separate Install GUI" bereitgestellte Benutzerverzeichnis nutzen - getestet - und ja, mit dem "Wait(500)" tritt dann auch in dieser Situation der Fehler nicht mehr auf.

Im Prinzip habe ich ja das Problem nicht mehr, da ich ja wieder mein altes Benutzerprofil nutze.

Aber andererseits bedeutet das Ergebnis dann aber, dass jeder, der LibreOffice auf seinem PC das erste Mal installiert - und damit auch ein nigelnagelneues Benutzerprofil erhält - mit genau diesem Problem konfrontiert wird - oder ?

Gruß
Hans-Werner ;-))

------ Originalnachricht ------

#4

hallo Hans-Werner,

Hallo Thomas,

[..]

Aber andererseits bedeutet das Ergebnis dann aber, dass jeder, der LibreOffice auf seinem PC das erste Mal installiert - und damit auch ein nigelnagelneues Benutzerprofil erhält - mit genau diesem Problem konfrontiert wird - oder ?

Dem ist wohl so. Ob es aber ein echter "Bug" ist oder nur einfach zufällig so auftritt kann ich Dir auch nicht sagen. Möglicherweise liest der Controller ja erst das Benutzerprofil aus vor dem "visible" schalten (ziemlich sicher sogar - denn dort steht die Größe und Position des zuletzt geöffneten Calc-Fensters - und die Daten braucht er ja...). Und je größer die registrymodification.xcu ist, um so länger dauert dieser Vorgang. Bei einem neuen Profil ist die sehr kurz - da geht es halt schneller;))

Vielleicht reicht ja auch schon ein   wait(100) - also 100 msec  - hab es nicht getestet.
Also, man könnte auch auf "nicht sicherer Makro-Programmierung" plädieren, weil man eine an dieser Stelle mögliche Zeitverzögerung nicht berücksichtigt.... aber sieh es pragmatisch. ne halbe Sek ist kaum sichtbar im Dokument - die Funktion gewährleistet auch bei einem ganz frischen Profil ... und je länger das Profil steht um so größer (und langsamer) wird es ja... also egal.
Lösung gefunden, abhaken:))

VG
Thomas

#5

Hallo Hans-Werner,

Mit meinem alten Benutzerprofil funktioniert es (unabhängig von den LO
Versionen) und mit einem neu angelegten Benutzerprofil tritt der Fehler
auf (unabhängig von den LO Versionen). Wie kann das Benutzerprofil
(unterschwellig) auf dieses Timing Einfluss nehmen ? Das "schnüffelt"
für mich schon ein wenig nach BUG ... oder habe ich da etwas in Deinen
Ausführungen völlig falsch verstanden ?

Vermutlich sorgt Dein altes Benutzerprofil wegen irgendwelcher
Einstellungen dafür, dass die Makroschritte grundsätzlich langsamer
ablaufen.

Gerade bei Geschichte mit sichtbaren/unsichtbaren Elementen habe ich so
ein Verhalten schon öfter erlebt: Die Makros laufen nicht so ab, dass
erst einmal auf das Ende des vorher gesetzten Befehls gewartet wird. So
muss z.B. beim Öffnen eines Berichtes aus einem (unsichtbaren)
Datenbankdokument genauso ein Wert von Wait(100) vorgegeben werden -
sonst bleibt der Bericht nur eine graue Oberfläche.

Gruß

Robert