[gelöst] Formularabsturz

[aladin]

Hallo herz4.

Meine häufig benutzen Formulare werden mittels oFrame.ContainerWindow.SetPosSize(lX,lY,lBREITE,lHOEHE,15) in Größe und Position immer gleich fixiert. Dies funktioniert nicht mehr einwandfrei. Mal tadellos, dann wieder nicht, ohne erkennbare Regelmäßigkeit oder Voraussetzung. Fast durch Zufall - oder aus Verzeiflung - probierte ich zuletzt erfolgreich ein Zerpflücken des Befehls. Zunächst nur Größe einstellen mit oFrame.ContainerWindow.SetPosSize(lX,lY,lBREITE,lHOEHE,12), dann nach kurzem Wait 10(ms) Position mit oFrame.ContainerWindow.SetPosSize(lX,lY,lBREITE,lHOEHE,3) und anschließendem abermaligen Wait jedoch mit mind. 500ms(!), sonst wird auch so die Position "ignoriert".

Ich beobachte seit längerem das gleiche Problem, möglicherweise schon unter AOO, bzw. bin ich da auch schon dran verzweifelt...
Nach Deinem Hinweis hier, habe ich versucht das Problem mal einzugrenzen.

Ich verwende folgendes Makro:

Code: Alles auswählen

Sub FormSize()

Print "Wait 1"
Wait 10000
Print "Wait 2"

	Dim oFrame as Object
	Dim oWin as Object

	Dim oStyle as Object
	Dim lHeight As Long
	Dim lWidth  As Long
	Dim iViewFaktorWidth as Integer
	Dim iViewFaktorlHeight as Integer
	Dim iPosSizeX as Integer
	Dim iPosSizeY as Integer
	Dim iPosSizeWidth as Integer
	Dim iPosSizeHeight as Integer
	
	iViewFaktorWidth=1440/TwipsPerPixelX()/2540*10000
	iViewFaktorlHeight=1440/TwipsPerPixelY()/2540*10000

	oFrame = StarDesktop.getCurrentFrame()
	oWin = oFrame.getContainerWindow()

'	iPosSizeX=oWin.getPosSize.X
'	iPosSizeY=oWin.getPosSize.Y
'	iPosSizeWidth=oWin.getPosSize.Width
'	iPosSizeHeight=oWin.getPosSize.Height

'	MsgBox("PosSizeX: "& iPosSizeX & Chr$(13) &"PosSizeY: "& iPosSizeY  & Chr$(13) &"iPosSizeWidth: "& iPosSizeWidth & Chr$(13) &"iPosSizeHeight: "& iPosSizeHeight,0,sTitle & " - Aktuelle Fenstergröße")
'	MsgBox("Max-Höhe: " & lHeightMax & Chr$(13)& "Max-Breite: " & lWidthMax,0,sTitle & " - Maximale Fenstergröße")

	if lHeightMax=0 OR lWidthMax=0 then
		oWin.IsMaximized = True
		Wait 1000
		print "Wait"
'		MsgBox("Max-Höhe: " & lHeightMax & Chr$(13)& "Max-Breite: " & lWidthMax,0,sTitle & " - Maximale Fenstergröße")
		lHeightMax=oWin.getSize.Height()
		lWidthMax=oWin.getSize.Width()
'		MsgBox("Max-Höhe: " & lHeightMax & Chr$(13)& "Max-Breite: " & lWidthMax,0,sTitle & " - Maximale Fenstergröße")
		oWin.IsMaximized = False
		Wait 1000
	end if

'	GlobalScope.BasicLibraries.LoadLibrary("XrayTool")
'	Xray oWin
	
	oStyle = ThisComponent.StyleFamilies.getByName("PageStyles").getByName("Standard")
	
	lWidth  = (oStyle.Width/10000*iViewFaktorWidth)+70
	lHeight = (oStyle.Height/10000*iViewFaktorlHeight)+100

'	MsgBox("Max-Höhe: " & lHeightMax & Chr$(13) &"Max-Breite: " & lWidthMax & Chr$(13) &"berechnete Höhe: "& lHeight & Chr$(13) &"berechnete Breite: "& lWidth,0,sTitle & " - Fenstergröße")

	if lWidth > lWidthMax then lWidth = lWidthMax
	if lHeight > lHeightMax then lHeight = lHeightMax

	oWin.setPosSize(oWin.getPosSize.X,0,lWidth,lHeight,15)
'	oWin.setPosSize(lWidthMax-lWidth,0,lWidth,lHeight,15)

'	iPosSizeX=oWin.getPosSize.X
'	iPosSizeY=oWin.getPosSize.Y
'	iPosSizeWidth=oWin.getPosSize.Width
'	iPosSizeHeight=oWin.getPosSize.Height

'	MsgBox("PosSizeX: "& iPosSizeX & Chr$(13) &"PosSizeY: "& iPosSizeY  & Chr$(13) &"iPosSizeWidth: "& iPosSizeWidth & Chr$(13) &"iPosSizeHeight: "& iPosSizeHeight,0,sTitle & " - Aktuelle Fenstergröße")
	

Ich habe bei mir festgestellt, das wait nicht zuverlässig funktioniert.

Löse ich das Makro manuell aus, dann funktioniert wait zuverlässig.

Wird das Makro hingegen beim Laden das Dokumentes ausgeführt, dann funktioniert wait gar nicht sondern die 2 Print-Anweisungen werden unmittelbar hintereinander ausgelöst.

Kannst Du bei Dir mal die 2 Print-Anweisungen einbauen und schauen, ob das bei Dir auch so ist?

Code: Alles auswählen

Print "Wait 1"
Wait 10000
Print "Wait 2"

Gruß und Danke
Heiko

[aladin]

Hallo herz4.

Meine häufig benutzen Formulare werden mittels oFrame.ContainerWindow.SetPosSize(lX,lY,lBREITE,lHOEHE,15) in Größe und Position immer gleich fixiert. Dies funktioniert nicht mehr einwandfrei. Mal tadellos, dann wieder nicht, ohne erkennbare Regelmäßigkeit oder Voraussetzung. Fast
...
die Position "ignoriert".

Ich beobachte seit längerem das gleiche Problem, möglicherweise schon unter AOO, bzw. bin ich da auch schon dran verzweifelt...
Nach Deinem Hinweis hier, habe ich versucht das Problem mal einzugrenzen.

...

Kannst Du bei Dir mal die 2 Print-Anweisungen einbauen und schauen, ob das bei Dir auch so ist?

Code: Alles auswählen

Print "Wait 1"
Wait 10000
Print "Wait 2"

Gruß und Danke
Heiko

Hat sich erledigt.
Bei mir war die Ursache, dass ein Makro, welches an ein anderes Ereignis geknüpft war, diese Probleme verursachte...

Gruß
Heiko

[herz4]

Hallo aladin,

es gibt tatsächlich Formularaktionen, die mit ihnen verknüpfte Makros doppelt(!) ausführen lassen. Musste ich auch erst lernen:

http://robert.familiegrosskopf.de/lo_hb ... kros.xhtml

Dort suchen: "Vor der Datensatzaktion werden zwei Implementationen nacheinander aufgerufen." - Kann man nach Robert G. (und meiner Erfahrung) bei Bedarf erfolgreich ausfiltern!

Gruß, herz4

[aladin]

es gibt tatsächlich Formularaktionen, die mit ihnen verknüpfte Makros doppelt(!) ausführen lassen. Musste ich auch erst lernen:
http://robert.familiegrosskopf.de/lo_hb ... kros.xhtml

Dort suchen: "Vor der Datensatzaktion werden zwei Implementationen nacheinander aufgerufen." - Kann man nach Robert G. (und meiner Erfahrung) bei Bedarf erfolgreich ausfiltern!

In dem Fall ging es nicht um Formularaktionen, sondern um Dein beschriebenes Problem mit dem Einstellen der Fenstergröße mittels:

Code: Alles auswählen

oFrame.ContainerWindow.SetPosSize(lX,lY,lBREITE,lHOEHE,15)

Dabei hatte ich auch Probleme, die aber darauf zurück zu führen waren, dass ein Makro gestartet wurde bei dem Ereignis "Dokument öffnen" und ein 2. Makro gestartet wurde bei "Ansicht wurde erzeugt". Dabei kam es zu dem Nebeneffekt, dass das Wait aus ersterem Makro nicht funktionierte.

Ich weiß nicht, ob das ein Bug ist, das ist schon sehr speziell...

Gruß
Heiko

[herz4]

Die Systemüberwachung gibt für die soffice.bin bei mir ~162MB Speicherplatzbedarf im RAM an, wenn ich den .odb-Container der Datenbank aufrufe, ohne ein einziges Formular, Tabelle oder Abfrage zu öffnen oder ein anderes LO-Dokument geöffnet zu haben (ohne Schnellstarter).
Rufe ich dann das "abstürzende" Formular auf, welches bis zum Anzeigen mehr als 15s benötigt, werden schon ~464MB Speicher belegt.
Wechsle ich dann zum nächsten Hauptdatensatz sind es schon ~505MB, beim 4., 5. auch mal ~525MB.
Wechsle ich im Unterformular den Datensatz, ändert sich die Speicherbelegung nicht signifikant.
Scrolle ich dann weiter runter, kommt fast verläßlich der Absturz, bei dem soffice.bin sofort(!) aus dem Arbeitsspeicher geschmissen wird.

Auf der Festplatte hat die Datenbank (externe Files) mit .odb-Container zusammen nicht einmal 20MB, auch wenn sie nicht per "Shutdown Compact" komprimiert wurde! Gut, kommen ein paar Files noch hinzu durch Treiber, Formular selbst, Abfragen; aber sage und schreibe über 300MB dafür?!

Ich habe mir diesen Arbeitsspeicherbedarf nicht vor dem Auftreten der Abstürze angeschaut, hatte einfach keine Veranlassung dazu. Es ging seinerzeit mit anfänglich 1GB RAM, dann wurden es 2GB, stets unter 18er Linux Mint 32bit. Jetzt habe ich 4GB, 19.1 und 64bit-Verarbeitung und sehr wahrscheinlich seither erst die Abstürze.

Fehlt es LO an der "Aufwärtskompatibilität"?! Oder anders: Irgendwann kommt jeder mal an seine Grenzen, auch gut geschriebene Software. Nur rechnet man nicht damit, dass bei Weiterentwicklung diese Limitierungen zunehmen. Auch ist es nur eine weitere Vermutung einer Ursache meiner Abstürze.

LO hat ab 6.0 das "Feintuning" des RAMs aus den leichter einstellbaren Optionen herausgenommen; jetzt muss man da wirklich Experte sein, um es überhaupt zu verstehen. Verstellen ohne Verständnis scheint mir heikel ...

[Freischreiber]

Hallo herz4,

ich schreibe nur, weil du ausdrücklich um kaffeesatzlesende Meinungen gebeten hast.

Ich weiß nicht, was für eine Datenbank du da genau hast: HSQL? Intern? Oder gesplittet?

RAM hatte ich bei deinem Problem gleich im Verdacht, weil du von 20 Unterformularen geschrieben hast. Vielleicht hilft dir das hier etwas weiter:
viewtopic.php?f=10&t=17976

Es gibt DB-Tabellen, die komplett im Arbeitsspeicher gehalten werden und gecachete. Die gecacheten sind langsamer im Zugriff, aber belasten den Arbeitsspeicher weniger. Eigentlich ist das aber, soviel ich weiß, die Standardtabelle bei interner HSQL-Datenbank.

Wenn du die 20 Unterformulare reduzieren kannst, hast du weniger RAM-Bedarf.

Und was natürlich immer eine Fehlerquelle ist, ist eine interne HSQL-DB an sich (alle Daten im .odb-Container). Gesplittet läuft stabiler.

Und

Gruß
Freischreiber

[herz4]

Hallo Freischreiber,

ich danke Dir für Deine mir willkommene Kaffeesatzleserei, auch ich benutze die (Daten)sichere externe HSQLDB via Java-Treiber.

Bei mir sind die Tabellen, die wirklich viele Daten enthalten, gecached. Nur Tabellen mit Typschlüsseln, 5, 10, 20 oder gar 100 Datensätze kommen bei mir (persistent) in den Speicher. Ich versprach mir damit ein schnelleres Bereitstellen von Pull-Down-Menüs. Allerdings habe ich das nie überprüft, ob da überhaupt ein Zeitgewinn spürbar ist ...

Ja, richtig, das mit dem Reduzieren der Unterformulare, eigentlich das Aufteilen des großen "PIM"-Formulars in kleinere, in welche mit jeweils weniger Unterformularen bleibt mir vielleicht nicht erspart. Streng genommen habe ich damit schon angefangen, indem ich die oberste Datensatzsuche in ein Extraformular ausgliederte. Dies war ehedem zwar kein Unterformular, sondern ein zweites auf oberster Ebene. Jedoch ist diese Ausgliederung einerseits mit viel Arbeit verbunden, nicht nur Formulare sind zu erstellen, sondern Makros sind anzupassen, einzelne vielleicht ganz neu zu konzipieren. Andererseits flutschte es bisher so gewohnt gut. (Ja, ich bin ein Gewohnheitstier.)

Wenn sich aber späterhin noch rausstellen wollte, dass der Fehler ganz woanders lag, meine Ausgliederung völlig umsonst war, wüchsen mir vielleicht die grauen Haare noch mehr, und, was schlimmer in meinem Alter wiegen könnte, der Zuwachs an grauen Zellen wäre kaum evident, nicht einmal signifikant, würde wohl eher durch allgemeinen Verfall untergehen ...

Da hoffe ich doch - vorerst und weiterhin - mehr auf die Schwarmintelligenz hier.

Gruß, herz4

[gogo]

ad Kaffeesatz:
ich vermute, dass sich der Treiber irgendwo ausklinkt. Die Dinger sind ja nicht dafür gemacht permanent parallel zu arbeiten, und auch nicht speziell an LO angepasst. Probleme bei komplizierten Strukturen sind da im wahrsten Sinne des Wortes "vorprogrammiert".

Rufe ich dann das "abstürzende" Formular auf, welches bis zum Anzeigen mehr als 15s benötigt, werden schon ~464MB Speicher belegt.
Wechsle ich dann zum nächsten Hauptdatensatz sind es schon ~505MB, beim 4., 5. auch mal ~525MB.
Wechsle ich im Unterformular den Datensatz, ändert sich die Speicherbelegung nicht signifikant.
Scrolle ich dann weiter runter, kommt fast verläßlich der Absturz, bei dem soffice.bin sofort(!) aus dem Arbeitsspeicher geschmissen wird.

... Du schilderst da ein programmtechnisches Horroszenario - auf meinem Kalender steht das Jahr 2019, selbst alte Rechner gehen heute mit riesigen Datenmengen flott um - Wenn da etwas 15 Sekunden braucht ist per se "der Hund drin".
Das Positionieren und Größenanpassen von Fenstern erfordert einen Haufen Kommunikation zwischen LO und dem Fenstermanager - Cinnamon ist da zwar recht fluffig, aber auch nicht bis ins Unendliche strapazierbar - der muss ja auch noch andere Prozesse die auf Deinem Rechner laufen miteinbeziehen.

Code: Alles auswählen

Wait 1000

... vergiss solche Konstruktionen - die haben noch nie dauerhaft funktioniert. Entweder es funktioniert weil programmtechnisch richtig oder es geht (so) nicht. Die meisten Probleme treten dabei auf, dass LOBasic verschiedene Threads parallel startet und daher nicht immer alles was Dein Makro braucht verfügbar ist. Um so etwas zu eruieren legst Du am besten auf OS-Ebene eine Logdatei an aus der Du klar erkennen kannst was sich im Verlauf der Makroausführung so tut. Das geht in LO und Linux ganz einfach. Makros die verdächtig sind erhalten mit "shell" zwei Log-Anweisungen:

Code: Alles auswählen

sub x
shell("bash -c 'echo `date +%s.%N` MakroX Start >> /tmp/my.log'")
... CODE
... CODE
... CODE
shell("bash -c 'echo `date +%s.%N` MakroX ENDE >> /tmp/my.log'")
end sub

Anhand der Start- und Stopzeiten kannst Du dann erkennen wo ggf die Probleme liegen könnten. Sollte ein Makro da aus der Reihe tanzen (weil z.B. das Öffnen-Ereignis irgendwie nicht zu der Zeit stattfindet zu der Du das erwartet hast...) dann weißt Du wo Du mit dem Schrauben beginnen musst.

[herz4]

Danke gogo für Deine ausführlichen Anregungen.

ich vermute, dass sich der Treiber irgendwo ausklinkt.

Kann gut sein. Woran merke ich das? Und noch wichtiger: Welche Grenzen muss ich - zukünftig - beachten? Kann auch gut sein, dass es an der Treiberschnittstelle nicht hakelt, denn ich habe trotz der vielen Abstürze weder Datenverluste noch Inkonsistenzen, zu keinem Zeitpunkt!

Du schilderst da ein programmtechnisches Horroszenario

Ich habe jüngst schon in den Formularen der zweiten Ebene die Datenmengen begrenzt, indem ich aus den verknüpften Tabellen nur die benötigten Datensätze per Where-Klausel ausfilterte. In der ersten Ebene sind es von Anfang an nur 20 aus mittlerweile knapp 3000. Ich konnte keine Besserung feststellen, weder bei Formularabstürzen noch bei der ersten Ladezeit. Ich werde jetzt darangehen, auch in den unteren Ebenen zu filtern.

Die "missliche" erste Ladezeit von mindestens 15s, wahrscheinlich eher 20s über Jahre(!) war nie mein wirkliches Problem, weil erstaunlicherweise nicht nur Datensatzwechsel auch heute noch sofort(!) bis ins unterste Formular erfolgen, sondern auch das erneute Laden der Daten des Formulars, nämlich dann, wenn in der obersten Ebene einer der zwanzig Datensätze gewechselt wird, alle weiteren "eins weiter rutschen" und der älteste rausfällt, die Ladezeit bis ins unterste Formular nur noch 1, maximal 2s beträgt. Wenn das Formular erst einmal "stand", konnte ich sehr gut damit arbeiten.

Das Positionieren und Größenanpassen von Fenstern erfordert einen Haufen Kommunikation zwischen LO und dem Fenstermanager ... der muss ja auch noch andere Prozesse die auf Deinem Rechner laufen miteinbeziehen.

Hier scheint mir am ehesten der "Hund begraben". Gut, die "anderen" Prozesse können wir vielleicht in den "Skat drücken". Erstens habe ich jetzt bei Problemsuche alles drum herum aus. Zweitens stürzt ausschließlich LO in den Abgrund, es werden im Falle lediglich alle weiteren LO-Fenster mitgerissen.

Also, diese "No-go-waits" muss ich ja auch nur im Zusammenhang mit Fensterpositionierung und -skalierung einbauen, damit diese abgearbeitet werden.

Zudem erfolgen meine Abstürze mittlerweile überhaupt nicht mehr im Zusammenhang von laufenden Makros. Das war ehedem bei einem einzigen(!) so, das nebenbei das Formular von unten nach oben "schnippste". Nunmehr gibt es nur noch ein einziges Szenario für den Absturz: Datensatzwechsel in einem (bestimmten) der Unterformulare und anschließend nach unten scrollen oder mit der der Maus das Formular hochschieben. Nach meinen Beobachtungen werden aber zuvor bei diesem Datensatzwechsel im Unterformular alle weiteren Anzeigen in weiteren Unterformularen aktualisiert. Wenn ich nicht nach unten scrolle kann ich tadellos weiter arbeiten, auch weitere Datensatzwechsel vollziehen lassen! Nur nicht scrollen oder anderweitig runter gehen!

Gogo, Deine Anregung mit Makrolog im Terminalfenster finde ich toll, werde ich bei nächster Gelegenheit probieren. Leider sehe ich - bisher - darin keine Hilfe für mein Absturzproblem.

Ich hoffe, damit wieder ein wenig mehr Kaffeesatz aufgetischt zu haben ...

[herz4]

Ich bringe neuen Kaffeesatz

Die Abstürze konnte ich noch nicht mittels Reduzierung der Formulardaten durch mehr Where-Klauseln in den Unterformularen erreichen. Auffällig war dabei, das ich in einem UFormular die Zahl der Datensätze von über 12000 auf gut 2000 reduziert habe, hernach aber der RAM-Speicherbedarf der soffice.bin nicht ein(!) MB kleiner wurde im Vergleich zu oben genannten Zahlen. (Ruft man die Tabelle der über 12000 Datensätze auf, wird diese unmittelbar mit den ersten 20...30 Datensätzen angezeigt. Springe ich in dieser Anzeige der bloßen Datentabelle zum letzten Datensatz, braucht selbst die Anzeige dessen gut 2, vielleicht 3s.)

Die Abstürze konnte ich - vorerst - fast ganz ausschalten, indem ich das Formular über die gesamte Bildschirmhöhe (1050px) aufzog. Damit waren mehr als 80% des Formulars sichtbar. Wenn ich nun meine Abstürze versuchte zu provozieren, blieben sie (vorerst) aus.

Sie kamen aber auf neue Art und Weise zurück. Wenn ich im über die Höhe aufgezogenen Formular eine Formulardatentabelle aufrufe, wird diese auch oben im Formular in gewohnter Weise gezeigt. Ich kann darin navigieren, die Anzeige im Formular wechselt damit einhergehend, unmittelbar. Wenn ich jedoch die Tabelle wieder schließe, stürzt - sehr oft, nahezu verlässlich - LO mit Formular in den Orkus.

Durch das Aufrufen der Tabelle, deren Anzeige oben im Formular, wird sein Inhalt zwangsläufig nach unten geschoben. Das "verkraftet" das von gogo hier zuvor beschworene Zusammenspiel von LO und dem Fenstermanager noch. Selbst die Datensatzwechsel werden noch (graphisch) vollzogen. Wenn aber die Tabelle ausgeschaltet wird, das Formular wieder nach oben rutscht, werden von diesem wieder die mehr als 80% sichtbar, während kurz zuvor vielleicht 50...60% sichtbar waren. Damit muss ein großer Teil der - graphischen - Aktualisierung bei dem Rücksprung "außerhalb des Bildschirms" erfolgen. Ob LO oder der Fenstermanager oder aber eben beide im Zusammenspiel bei dieser Aufgabe versagen, ist mir letztlich schnuppe. Ich meine, dicht an der Fehlerquelle dran zu sein - bis mich jemand eines Besseren belehrt.

Deshalb werde ich zusehen, mein Formular breiter auf dem Bildschirm aufzuziehen, die Datenfelder und -boxen neu verteilen, wahrscheinlich bekomme ich alles selbst auf nur einem Teil von 1050x1980px unter. Die in früheren Jahren nötige Beschränkung wegen kleinerer Bildschirme zusammen mit dem Anspruch guter Lesbarkeit gibt es ja nicht mehr. So war meine 2-Seiten-Formular-Darstellung nur einmal "historisch" entstanden.

Und sie hatte auch einen Vorteil. Man konnte das nunmehr "veraltete" Formular auch auf kleineren Bildschirmen, etwa einem Laptop verwenden. Ich kann mich ja noch zwischen einem großen oder zwei, drei kleinen Formularen entscheiden ...

Ich sehe auch einen Zusammenhang zwischen dem Begriff "Drawpage" und dem nicht kleiner werdenden RAM-Bedarf der soffice.bin. Wahrscheinlich muss zur Erstellung des - anzuzeigenden - Formulars ähnlich viel intern gerechnet werden, müssen Daten verarbeitet werden, vergleichbar mit dem Aufwand bei Bildbearbeitungen. Das vermute ich zumindest.

Ich will noch nicht als "gelöst" markieren, nicht weil es eigentlich nicht zu lösen ist, sondern weil ich noch nicht 100%ig sicher bin, des Pudels Kern getroffen zu haben. Dafür hatte ich zu viele "Rückschläge" in jüngerer Vergangenheit. Und ich freute mich weiterhin über Eure Meinung dazu!