Programmabsturz beim Speichern (gelöst)

Programmierung unter AOO/LO (StarBasic, Python, Java, ...)

Moderator: Moderatoren

erikafuchs
******
Beiträge: 690
Registriert: Di, 13.02.2007 17:38
Wohnort: Büttelborn

Re: Programmabsturz beim Speichern

Beitrag von erikafuchs »

Lieber Balu, lieber Tom,
vielen Dank euch Beiden, da habt ihr euch ja schon mal tief in mein Chaos gekniet. Auf Balus Rat hatte ich mich ja schon mal drangemacht die verschiedenen Definitionen zu sortieren. Ich glaube dsheet und esheet und zsheet usw. beziehen sich jetzt immer auf das gleiche Tabellenblatt. An die Variablendeklarationen am Anfang habe ich mich nicht rangetraut. Es sind aber auch viele. Die sind im Laufe der Jahre entstanden und ich habe da eindeutig den Überblick verloren. Nach der Devise "never change a running sytem" habe ich sie lieber nicht angetastet. Nun gut, jetzt rennt das System aber anscheinend nicht mehr so richtig. Viele dieser Variablen werden halt über mehrere subs abgefragt. Sie werden unter "Aufgabenerstellung" mit Werten gefüllt, die z.B. unter "Lösungsvergleich" wieder abgefragt werden. Der Unterschied zwischen "global" und "public" hat sich mir bisher noch nicht erschlossen, da muss ich wohl noch mal nachlesen. Und zu meiner Schande muss ich gestehen, dass mir bisher nicht bewusst war, dass das "o" in "oDoc" und "osheet" sich auf "object" bezieht - auweh! Vieles ist immer noch doppelt und ich traue mich nicht dran, hier mein Programm zu überarbeiten. Es gibt derartig viele Möglichkeiten von A nach B zu kommen, dass es hier immer wieder zu Fehlermeldungen kam, wenn ich Doubletten entfernt habe.
1. Im Modul AnfangEnde unter 'allgemeine Einstellungen : seite as string
2. Im gleichen Modul...unter 'Zeichnen : seite as integer
Der arme Kompiler....
Richtig muss der Übergabeparameter als Integer übergeben werden... das muss sichergestellt sein! Sonst: Absturz....
Das mit der "seite" habe ich geändert. das hat erstmal noch nicht geholfen.
ich finde auch keinen Button zum anklicken um den besagten Dialog (welchen überhaupt?) zu starten.
Lieber Balu, du kennst ja meinen Rechentrainer noch mit Startknöpfen - zwischenzeitlich werden die Aufgaben durch Klick auf die Namen der Aufgabentypen entweder auf der Seite "übersicht" oder (beim Test - was ja jetzt zu Problemen führt!) auf der Seite "Übersicht_Test" gestartet. Dort wird das sub "Auswahl" im Modul "Aufgaben" aufgerufen, das zu den verschiedenen Aufgaben führt.
Mit (seite) übergibst Du den Sub-Aufruf einen Parameter. Aber von wo wird dieser ursprünglich weiter gereicht damit er in dieser Sub empfangen wird? In irgendeinem Modul in irgendeiner Sub muss ja 'seite' defeniert werden. Blos wo?
Das passiert mit

Code: Alles auswählen

	woher=Thiscomponent.getCurrentController.getActiveSheet().name
	if woher="Übersicht_Test" then
		seite=3
	else
		seite=1 	
	end if	
unter "Aufgabenstellung.
Es ist ja nur eine Vermutung, aber es könnte sein das die dazugehörige deklaration der Variablen 'seite' nicht ganz korrekt ist. Das Du sie wohl öffentlich mit DIM deklariert hast, aber es besser wäre wenn sie PUBLIC oder GLOBAL ist. Ich würde das an deiner Stelle noch mal überprüfen.
kannst du mir das bitte nochmal erklären?
Code schaue ich mir jetzt nicht mehr an.
hier geht es nur um dieses:

Code: Alles auswählen

sub ZeichnungLoeschen (seite as integer)
	oPage=ThisComponent.drawpages(seite)
	do while oPage.count>0
    	oGrafik=opage.getbyindex(oPage.count-1)
    	oPage.remove(oGrafik)
	loop 			
end sub
ich kann mich erinnern, dass ich damit schon früher Probleme hatte und es zu Programmabstürzen kam wenn auf einer Seite keine Grafiken vorhanden waren. Könnt ihr mir dazu was sagen?
Hoffnungsvoll
Pit
erikafuchs
******
Beiträge: 690
Registriert: Di, 13.02.2007 17:38
Wohnort: Büttelborn

Re: Programmabsturz beim Speichern

Beitrag von erikafuchs »

Nachdem ihr euch so ins Zeug gelegt habt, habe ich hier meine abgespeckte Version mal ergänzt. Es gibt jetzt den Aufgabentyp "Zahlenstrahl". Wenn man den aus "übersicht" aufruft ist alles ok, man kann auch auf "abbrechen" klicken ohne dass es zum Absturz führt. Macht man das von der Seite "Übersicht_Test" aus, stürzt das Programm unweigerlich ab.
https://www.dropbox.com/s/vyw4x56gtlb9j ... 7.ods?dl=0
Benutzeravatar
balu
********
Beiträge: 3810
Registriert: Fr, 24.08.2007 00:28
Wohnort: Warstein

Re: Programmabsturz beim Speichern

Beitrag von balu »

Hallo Pit,

Und zu meiner Schande muss ich gestehen, dass mir bisher nicht bewusst war, dass das "o" in "oDoc" und "osheet" sich auf "object" bezieht - auweh!
Nein! Das ist keine Schande.
Tom sagte ja:
Also hier empfehle ich, dringend den Code zu bereinigen und zu überarbeiten. Bezeichen die Variablen schon für Dich und zum Verständnis mit Typen-Zuordnung, das macht das Leben leichter:)

Also: sSeite für einen String, iSeite für eine Integer, nSeite für ne Zahl (double oder so),....
Und das ist kein MUSS, sondern ehern eine leicht zu merkende "Eselsbrücke". Wenn vor dem Variablennamen ein kleiner Buchstabe steht, dann deutet dieser auf den Variablentyp hin.


Zu der Variablendeklaration am Modulanfang.
Ich weiss ja selber wie schwer das wird, wenn es sich um sehr viele Variablen handelt und man leicht den Überblick verlieren kann. Hier aber nach der Devise zu arbeiten "Never change ..." ist nicht ganz so optimal. Was glaubst Du wohl wieviel Zeit und Arbeit ich in meinem ersten Großprojekt nur für dieses Thema investiert hatte?

Und natürlich hatte ich auch in meiner anfangszeit mir so manchen Code von hier und da zusammengesucht und zusammengestückelt. Bis das ich überhaupt keinen Überblick mehr hatte. Also wurden die Hemdsärmel hochgekrämpelt und los ging. Solcch Dinge wie oSheet1 oder oSheet2 etc. flogen raus und wurden durch "Sprechende Namen" ersetzt, wie z.B. oHauptblatt oder oBlattübersicht etc.

Wenn du jetzt z.B. dsheet durch einen "Sprechenden Namen" ersetzen willst, dann geht das in der BASIC-IDE doch recht einfach. Denn es gibt dort auch eine Suchen und Ersetzen-Funktion. Einfach nach dSheet suchen und durch (als Beispiel) oÜbersicht ersetzen, und mit der Option in allen Modulen ersetzen, fertig.

Es gibt derartig viele Möglichkeiten von A nach B zu kommen, dass es hier immer wieder zu Fehlermeldungen kam, wenn ich Doubletten entfernt habe.
Ein Problem dabei könnte vielleicht sein (aber ohne das ich es wirklich weiss von der Datei her gesehen), das eine Variable einmal öffentlich und ein zweites mal Lokal innerhalb einer Sub deklariert war. Und wenn die öffentliche deklaration gelöscht wurde, diese aber am wichtigsten war, und nur noch die Lokale übrig blieb, es durchaus zu einer Fehlermeldung kommen kann. Ist eine mögliche Ursache.

Also wenn Doubletten entfernen, darauf achten wo sie gelöscht wird. Wird sie NUR innerhalb einer Sub benötigt, dann auf keinen Fall in der dementsprechenden Sub löschen.

Der Unterschied zwischen "global" und "public" hat sich mir bisher noch nicht erschlossen, da muss ich wohl noch mal nachlesen.
Ja, das empfehle ich dir auch.

zwischenzeitlich werden die Aufgaben durch Klick auf die Namen der Aufgabentypen ....
Ach soooo is dat!
Das muss einem dumbatz wie mir doch gesagt werden :lol:

Das mit der "seite" habe ich geändert. das hat erstmal noch nicht geholfen.
Was hasst Du geändert?

erikafuchs hat geschrieben:
Es ist ja nur eine Vermutung, aber es könnte sein das die dazugehörige deklaration der Variablen 'seite' nicht ganz korrekt ist. Das Du sie wohl öffentlich mit DIM deklariert hast, aber es besser wäre wenn sie PUBLIC oder GLOBAL ist. Ich würde das an deiner Stelle noch mal überprüfen.
kannst du mir das bitte nochmal erklären?
Bis zur Antwort von Tom dachte ich mir: Die Variable ist wohl deklariert worden, aber aus einem mir unbekannten Grund ist sie auf dem Weg zum Einsatzort verschwunden. Und ich persönlich hatte mal eine ähnliche Erfahrung mit DIM gemacht (ist aber schon sehr lange her). Erst durch den Einsatz von PUBLIC konnte ich das Problem lösen.
Ja!
Ich weiss!
Für den echten Profi ist das vielleicht nicht so recht zu glauben, aber bei mir hatte es damals geholfen.
Und wenn Dudich selber noch mal intensiver mit PUBLIC oder GLOABAL auseinander setzt, was Du ja auch vor hast, dann wirst du das besser verstehen.

erikafuchs hat geschrieben:
Mit (seite) übergibst Du den Sub-Aufruf einen Parameter. Aber von wo wird dieser ursprünglich weiter gereicht damit er in dieser Sub empfangen wird? In irgendeinem Modul in irgendeiner Sub muss ja 'seite' defeniert werden. Blos wo?
Das passiert mit

Code: Alles auswählen

	woher=Thiscomponent.getCurrentController.getActiveSheet().name
	if woher="Übersicht_Test" then
		seite=3
	else
		seite=1 	
	end if	
unter "Aufgabenstellung.
Ah, okay und Danke.

ich kann mich erinnern, dass ich damit schon früher Probleme hatte und es zu Programmabstürzen kam wenn auf einer Seite keine Grafiken vorhanden waren.
Aufpassen mit dem Wort "Grafiken"!
Früher hatte ich das Wort nämlich auch missverstanden. Denn in diesem Falle arbeitet man in Calc auf zwei Ebenen. Die erste ist das Tabellenblatt, und die zweite ist die wo man etwas Zeichnen kann. Und zu dem Zeichnen gehören nicht nur Bilder oder Grafiken, sondern auch die Grafik Steuerelemente wie z.B. ein Button. Und wenn man also alle Grafiken löschen will, dann werden auch die Buttons, so fern welche vorhanden, zwangsläufig mit gelöscht.


Kommen wir zu deinem letzten Beitrag.
Ich kann deine Aussage bejaen, aber auch verneien.
Im ersten Anlauf wusste ich nicht das ich die dementsprechende Zelle doppelklcken musste, und nicht nur einfach klicken. Also bin ich vom Blatt *übersicht* auf *Übersicht_Test* gewechselt und hatte dort den doppelklick ausgeführt. Klick auf Abbrechen und alles war Okay.

Nun bin ich wieder auf *übersicht* gewechselt und dort den doppelklick. Ergebniss: Und tschüss....


Gruß
balu
Sei öfter mal ein Faultier, sag öfter mal "Ach was!" Dann kriegst du keinen Herzinfarkt, und hast ne menge Spass.

wehr rächtschraipfähler findet khan si behalden :D
erikafuchs
******
Beiträge: 690
Registriert: Di, 13.02.2007 17:38
Wohnort: Büttelborn

Re: Programmabsturz beim Speichern

Beitrag von erikafuchs »

Vergesst das - wäre ja auch zu schön gewesen!


Nichts von Alledem. Hier ist der Fehler:
Zwischenablage01.jpg
Zwischenablage01.jpg (68.42 KiB) 3263 mal betrachtet
Wenn ich diese Zellen in "Übersicht_Test" entferne, ist der Spuk weg.
Und was ist da? Z.B. folgender Inhalt:
=SUMME(C8:C29;C31;C33;C33;C35:C38;C42;C47)
das mag er nicht. Hier stürzt tatsächlich das Programm beim Speichern ab.
erikafuchs
******
Beiträge: 690
Registriert: Di, 13.02.2007 17:38
Wohnort: Büttelborn

Re: Programmabsturz beim Speichern

Beitrag von erikafuchs »

Und nochmal:
Zurück zu Balus Idee. Ich habe mal nicht nur die obengenannten Inhalte gelöscht sondern noch den Rest der Zellen mit Berechnungen und habe nur die Verknüpfungen übriggelassen.
https://www.dropbox.com/s/xmhx9r7vkadxj ... 8.ods?dl=0
Siehe da, es gelingt mir nicht mehr, den Ansturz zu erzwingen. Ist es so, dass vor, oder während des Speicherns noch die ganzen Zellinhalte berechnet werden und dazu noch meine Inhalte auf der Drawpage gelöscht werden und das Speichern da überfordert ist? Man erkennt ja richtig, dass beim Öffnen von "Zahlenstrahl" und anschließendem Klicken auf "Abbrechen" im Menue der Computer eine Weile rödelt. Gerade beim Zahlenstrahl muss ja jedes einzelne Strichelchen in eine Schleife entfernt werden. Habt ihr dazu eine Idee, wie man das in den Griff bekommt?
Benutzeravatar
balu
********
Beiträge: 3810
Registriert: Fr, 24.08.2007 00:28
Wohnort: Warstein

Re: Programmabsturz beim Speichern

Beitrag von balu »

Hallo Pit,

ich kann bestätigen das durch das löschen der besagten Zelle es läuft.
Ist es so, dass vor, oder während des Speicherns noch die ganzen Zellinhalte berechnet werden
Wenn sich der Zellinhalt geändert hat, dann ja.

und dazu noch meine Inhalte auf der Drawpage gelöscht werden und das Speichern da überfordert ist?
Überfordert im weitestem Sinne.
Auch wenn StarBasic kein 911er Porsche ist, so ist ein Makro schneller abgearbeitet als alle Zellen in einer Calc-Datei neu zu berechnen.

Man erkennt ja richtig, dass beim Öffnen von "Zahlenstrahl" und anschließendem Klicken auf "Abbrechen" im Menue der Computer eine Weile rödelt.
Was soll ich sagen, mein Rechensklave rödelt nicht wirklich, aber ich kann schon sehen das erst der Dialog geschlossen wird, und anschließend die Grafik gelöscht wird. Wohl nicht immer, weil meistens kein Zeitunterschied zu sehen ist, aber hin und wieder sehe ich es. Um das ganze mal in Zahlen auszudrücken:
-> Schnellstes schließen des Dialogs mit Grafik löschen = 0 sekunden.
-> Zeitdifferenz zwischen Dialog schließen und Grafik löschen ca. 1,5 sekunden. Höchstens!
Getestet mit 'Rechentrainer Gerüst 07.ods'.

Da wir nicht wissen wie lange das bei dir dauert, können wir auch nicht sagen was man da machen kann. Aber ich würde schon sagen das es auf den persönlichen Rechensklaven ankommt. Ich hatte meinen anfang letzten Jahres auf einen AMD FX 4300 QUAD-CORE aufgerüstet. Und an einigen Stellen merke ich schon einen gewissen Geschwindigkeitszuwachs, selbst in OpenOffice.


Deine letzte Datei schaue ich mir jetzt nicht mehr an. Denn, auch wenn es nichr danach aussieht, so habe ich mich für heute genung mit deinem Problem befasst.



Gruß
balu
Sei öfter mal ein Faultier, sag öfter mal "Ach was!" Dann kriegst du keinen Herzinfarkt, und hast ne menge Spass.

wehr rächtschraipfähler findet khan si behalden :D
erikafuchs
******
Beiträge: 690
Registriert: Di, 13.02.2007 17:38
Wohnort: Büttelborn

Re: Programmabsturz beim Speichern

Beitrag von erikafuchs »

auch wenn es nichr danach aussieht, so habe ich mich für heute genung mit deinem Problem befasst.
absolutely!
Toxitom
********
Beiträge: 3768
Registriert: Di, 12.08.2003 18:07
Wohnort: Wiesbaden
Kontaktdaten:

Re: Programmabsturz beim Speichern

Beitrag von Toxitom »

Hallo EriKafuchs,
...Der Unterschied zwischen "global" und "public" hat sich mir bisher noch nicht erschlossen, da muss ich wohl noch mal nachlesen....
Zumindest hierfür eine kurze "Erhellung";))

In Basic müssten Variablen gar nicht deklariert werden - das macht der Kompiler automatisch, immer dann, wenn er sie braucht;) Wäre aber sehr schlechter Programmierstil und sollte unbedingt verminden werden. Mit der expliziten Deklaration legst Du nicht nur den Typ der Variablen fest (as...) sondern eben auch die Sichtbarkeit - also die Wirksdamkeit der Variablen.
Grundsätzlich werden Variablen mit der Schlüsselwort "dim" deklariert, einzige Ausnahme sind Übergabevariablen bei einem Funktionsaufruf - die wird ohne Schlüsselwort deklariert (Bsp: "function abc(s as string)" - Variable s ist deklariert).
Dabei gilt die folgende Bedeutung: Variablen sind nur sichtbar in dem Umfeld, in dem sie deklariert wurden. Werden Sie innerhalb einer Funktion erzeugt, so sind sie auch nur innerhalb der Funktion sichtbar und nutzbar. Das ist im Übrigen die bevorzugte Variante ud sollte immer wenn möglich genutzt werden. Die Funktion (sub oder function) ist also die unterste Stufe.
Die nächste - übergeordnete Stufe wäre das Modul. Damit Varaiblen Modulweit genutzt werden können, müssen Sie am Anfang des Moduls deklariert werden, vor der ersten Sub oder Function. Nun gelten die Variablen innerhalb des Moduls und können von jeder dort befindlichen Funktion oder Sub genutzt und geändert werden. Wird das Programm neu gestartet, werden alle Variablen des Moduls neu initialisiert (also auch zurückgesetzt).
Auch hier wird "dim" genutzt, alternativ könnte "private" verwendet werden, erfüllt in diesem Fall den gleichen Zweck ud war urspürünglich dafür vorgesehen.
Die nächst höherer Hierarchieebene ist nun die Bibliothek. Sollen Variablen bibliotheksweit genutzt werden, brauchst Du das Schlüsselwort "public" für die Variablen, sie müssen ebenfalls in einem Modul vor irgendeiner Sub oder function deklariert werden. Auch diese Variablen Werden beim Start eines Programms aus der Bibliothek neu initialisiert.
Faktisch ist der Unterschied zwischen "dim" und "public" unter Windows nicht vorhanden. Beide initialisieren Bibliotheksweit. Unter Linux gab es früher die Unterschiede, dort war "public" zwingend. Hab es heute noch nicht ausprobiert...

Die oberste Ebene schließlich ist "global" - in dem Fall ist die Variable im Rahmen von LibreOffice /AOO sichtbar und änderbar - also bibiotheksübergreifend. Wird in der Praxis ganz selten benötigt und birgt einige Gefahren mit sich. Die Inhalte der Variablen bleiben solange bestehen, wie der AOO/LO Prozess läuft - und können somit von jedem Makrocode ausgelesen und geändert werden! Wenn nicht zwingend nötig - nie benutzen!

Wird eine Variable nicht deklariert, wird sie vom Kompiler innerhalb einer Funktion definiert, wenn sie dort erstmalig vorkommt. Kleinst mögliche Lösung.

Also: zum Schnellmerken:
Variable, die nur innerhalb einer Funktin benötigt werden - mit Dim deklarieren (Normalfall)
Modul- oder Bibliotheksweite Variablen (so was wie Dialog-Variable) mit "dim" oder besser "public" am Modul Anfang oder in einem eigenen Modul deklarieren. Fertig..


VG
Tom
Unterstützer LibreOffice, zertifizierter Trainer und Berater
Bücher: LibreOffice 6- Einstieg und Umstieg
Makros Grundlagen - LibreOffice / OpenOffice Basic
Stephan
********
Beiträge: 12369
Registriert: Mi, 30.06.2004 19:36
Wohnort: nahe Berlin

Re: Programmabsturz beim Speichern

Beitrag von Stephan »

Siehe da, es gelingt mir nicht mehr, den Ansturz zu erzwingen. Ist es so, dass vor, oder während des Speicherns noch die ganzen Zellinhalte berechnet werden und dazu noch meine Inhalte auf der Drawpage gelöscht werden und das Speichern da überfordert ist? Man erkennt ja richtig, dass beim Öffnen von "Zahlenstrahl" und anschließendem Klicken auf "Abbrechen" im Menue der Computer eine Weile rödelt. Gerade beim Zahlenstrahl muss ja jedes einzelne Strichelchen in eine Schleife entfernt werden. Habt ihr dazu eine Idee, wie man das in den Griff bekommt?
Ich rate dann mal meinerseits mit.

Ich würde testweise statt .store() Dispatcher-Code verwenden, also:

Code: Alles auswählen

sub Main
rem ----------------------------------------------------------------------
rem define variables
dim document   as object
dim dispatcher as object
rem ----------------------------------------------------------------------
rem get access to the document
document   = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

rem ----------------------------------------------------------------------
dispatcher.executeDispatch(document, ".uno:Save", "", 0, Array())
end Sub

Gruß
Stephan
Benutzeravatar
balu
********
Beiträge: 3810
Registriert: Fr, 24.08.2007 00:28
Wohnort: Warstein

Re: Programmabsturz beim Speichern

Beitrag von balu »

Hallo Pit,

meine Augen sind wirklich nicht mehr die besten, aber dennoch hatte ich alles mögliche versucht deinem Problem auf die Schliche zu kommen. Und trotz aller zusammenhängende Code Untersuchungen, kam ich auf keinen Grünen Zweig.

Da ja der Makrocode durch ein Tabellenereigniss angestoßen wird, hatte ich dementsprechend die einzelnen dazugehörigen Subs etc. mir angeschaut. Konnte aber soweit nix außergewöhnliches feststellen. Das einzige was mir persönlich echt missfällt ist folgendes (Codeausschnitt ist nur als Beispiel zu sehen).

Code: Alles auswählen

	if testende then 
		exit sub
'		Zwischenspeichern
	end if
Du arbeitest sehr viel mit 'exit Sub'. Da mögen unsere Vollprofis vielleicht anderer Meinuung sein, aber wie schon gesagt gefällt mir das persönlich nicht.
Also hatte ich das gestern, bevor Du mit der Lösung der Zelle ankamst, das mal mit 'goto finito' geändert. Und anfangs schien dass auch zu funktionieren, aber die Freude war nur von kurzer dauer.

Dann hatte ich mir deine Formel mal genauer angeschaut.

Code: Alles auswählen

=SUMME(C8:C29;C31;C33;C33;C35:C38;C42;C47)
Okay. Sie sah für mich im ersten Augenblick ungewohnt aus. Und ferner wird die Zelle C33 doppelt addiert, aber das ist ein anderes Thema.
Da ich schon lange nicht mehr auf diese Art und Weise mit =SUMME() gearbeitet habe, musste ich tatsächlich ... man überlege sich das nur mal was ich balu da jetzt sage :lol: ... in der Hilfe nachschauen ob das so korrekt ist. Und im groben sollte das wohl so stimmen. Aber dennoch hate ich mal die Formel andersrum aufgebaut, z.B. so rum.

Code: Alles auswählen

=SUMME(C8:C29)+SUMME(C35:C38)+SUMME(C31;C33;C42;C47)
Das änderte aber auch nix.
Also nur mal so zur Sicherheit hatte ich in einer Blanko Calc-Datei die dementsprechenden Zellen aus deiner Datei dort rein kopiert und dort dann auch die deinige Formel eingetragen.
Ergebniss: Es wird richtg gerechnet.
Also kann die Formel nicht allein Schuldig sein.

Vielleicht überschneidet sich im Makro irgendetwas mit der besagten Formelzelle, so das das Makro und Calc gleichzeitig darauf zugreifen. Und da fiel mir

Code: Alles auswählen

oCellCursor.GotoEndOfUsedArea(True)
ein. Ich weiss, ein Plöter Gedanke, aber ich wollt ja nur mal schauen. Jedoch konnte ich da wirklich nichts außergewöhnliches feststellen.

Das war so gesehen mein "Rapport" von gestern. ;-)

Und in der vergangenen Nacht kam mir da ein ganz Dummer Gedanke. Da sich es mir einfach nicht offenbaren wollte warum eine Formelzelle ein System zum Absturz bringen kann, kramte ich in meinem kaputtem Gehirn rum. Und da war doch tatsächlich noch etwas. Und als ich vorhin mir die Antworten von Tom und Stephan, ganz besonders die von Stephan durchlas
Stephan hat geschrieben: Ich rate dann mal meinerseits mit.
ging mir nur noch eins durch den Kopf:

"Hallo! Stephan rätselt mit? Und greift auf Dispatch zu? Wirklich seltsam."

Aber das veranlasste mich jetzt um so mehr meinen Nachtgedanken zu überprüfen.
Und ich sollte Recht bekomen.
Aber zu erst noch eine fast kleine nebensächlichkeit, die mich zu meinem Nachtgedanken anregte.
erikafuchs hat geschrieben: Die sind im Laufe der Jahre entstanden und ich habe da eindeutig den Überblick verloren. Nach der Devise "never change a running sytem" habe ich sie lieber nicht angetastet.
Und ja! Du bist tatsächllich der hervorgehobene Passage treu geblieben.

Und ich hatte dich schon vor ein paar Jahren, als ich das erste mal mit deinem damaligen Rechentriner hier in Kontakt kam, darauf hingewiesen. Und jetzt kommt mein bestätigter Nachtgedanke.

Dein Rechentrainer ist KEINE reine CALC-Datei. Er beruht auf einer EXCEL-Datei.
Anders ausgedrückt.
Früher war es eine Excel-Datei, die dann in Calc weiter bearbeitet wurde und ab dann als Calc-Datei gespeichert wurde.

Und ich hatte dich schon damals deswegen gewarnt, dass aus hier im Forum gemachte Efahrungen es durchaus zu Problemen kam, wenn eine Excel-Datei in Calc weiter ausgebaut (oder ähnliches) wird. Und ich meine mich daran zu erinnern, das ich dir schon damals dringend empfohlen habe die Datei komplett neu zu machen. Aber darauf aufpassen das nichts direkt aus der ZWITTER-Datei in die neue reine CALC-Datei kopiert wird.

Ich will wohl meine Hand nicht dafür ins Feuer legen, das dann dein Problem wirklich gelöst ist (und die Formelzelle da bleiben kann wo sie war), aber ich gehe mit meiner Hand seeeehr nahe ans Feuer.

Also noch mal in kurzen Worten.
Mach die Datei komplett neu! Und zwar nur in Calc!

Ich weiss nicht wie das unsere Vollprofis sehen, aber ich bleibe dabei das es wirkich ratsam ist die Datei komplett neu zu machen.



Gruß
balu
Sei öfter mal ein Faultier, sag öfter mal "Ach was!" Dann kriegst du keinen Herzinfarkt, und hast ne menge Spass.

wehr rächtschraipfähler findet khan si behalden :D
erikafuchs
******
Beiträge: 690
Registriert: Di, 13.02.2007 17:38
Wohnort: Büttelborn

Re: Programmabsturz beim Speichern

Beitrag von erikafuchs »

Lieber Tom,
toll, eine sehr schöne Erklärung. Ich habe nur in fremden Codes schon gesehen, dass Variablen explicit als "public", "private", bzw "global" definiert wurden. Bei mir steht ja jeweils nur "dim ...as". Nach deinem Buch und deiner Erklärung hier, scheint es mir ja aber zu genügen, die Variable in der Funktion/im sub, im Modul oder ganz am Anfang zu definieren - "global" erschien mir nicht sinnvoll. Ich hatte ja auch halbherzig (wie in deiner Erklärung empfohlen) die Variablen innerhald der Funktion/des sub zu definieren, das hat aber immer wieder zu Problemen geführt, weil die Variable woanders halt auch noch mal abgefragt wird. Daher sind wohl auch die (wahrscheinlich) unnötigen doppelten Variablendefinitionen am Anfang meines Makros und nochmals innerhalb der Funktion/sub entstanden. Balu hat mir empfohlen, die Definitionen nochmals zu überprüfen, ich sehe hier aber erstmal nicht inwiefern mir das hier hilft und weiß nicht was ich da ändern kann. Ich verspreche, dies in nächsten Projekten ordentlicher zu lösen!
Lieber Stefan,
zunächst schien das tatsächlich zu funktionieren. Das Programm scheint seltener abzustürzen - leider tut es dies aber immer noch. Vielleicht ist mein armes kleines Laptop hier im Urlaub ja überfordert - es kommt jetzt zu gravierenden Abstürzen (sogar mit Fehlermeldung), die jetzt einen Kaltstart erfordern, oder ich muss den Dienst "soffice.bin" beenden.

Langsam bin ich am Verzweifeln, ich hatte mein Programm am Ende der Herbstferien schon zugesagt und entsprechende Erwartungen geschürt. Das Programm raubt mir schon den Schlaf. Dabei hatte ich die Idee, dass das Problem nicht darin besteht, dass das Speichern schneller als das Berechnen erfolgt. Wenn ich die Programmausführung in der Zeile vor "store" mit "print" unterbreche, ist ja zumindest das Löschen der vielen Objekten auf der Drawpage beendet. Ich konnte auch ein Screnshot erzeugen, indem man sieht, wie der Speichervorgang (mit Dispacher Code) mittendrin abbricht:
Zwischenablage02.jpg
Zwischenablage02.jpg (103.86 KiB) 3086 mal betrachtet
... ich fürchte aber ein Kontakt mit dem application support team wird mir nicht weiterhelfen:
Zwischenablage03.jpg
Zwischenablage03.jpg (46.86 KiB) 3086 mal betrachtet
Ich befürchte, es ist doch ein Fehler in meinem Code. Warum der beim Start von der einen Seite "Übersicht" nicht zum Tragen kommt, beim Start von der Seite "Übersicht_Test" aber schon, ist mir vollkommen schleierhaft. Ich komme auf meine Frage zu diesem Code zurück:

Code: Alles auswählen

sub ZeichnungLoeschen (seite as integer)
	oPage=ThisComponent.drawpages(seite)
	do while oPage.count>0
    	oGrafik=opage.getbyindex(oPage.count-1)
    	oPage.remove(oGrafik)
	loop 			
end sub
... ich bin mir sicher, dass ich hiermit schon Probleme hatte.
Stephan
********
Beiträge: 12369
Registriert: Mi, 30.06.2004 19:36
Wohnort: nahe Berlin

Re: Programmabsturz beim Speichern

Beitrag von Stephan »

ging mir nur noch eins durch den Kopf:

"Hallo! Stephan rätselt mit? Und greift auf Dispatch zu? Wirklich seltsam."
Aufmerksam, das Dir das auffällt, denn es sollte durchaus auffallen.

Der Vorschlag mit dem dispatcher-Code IST ernst gemeint, denn .uno:save sollte versuchen Konflikte aufzulösen, wohingegen .store() einfach speichert, komme was wolle. Ob das in Praxis hilft, weiß ich nicht vorab.
(mir hat dispatcher-Code z.B. einmal bei einem .Close geholfen was das Programm abstürzen ließ und wo ich keine Ursache fand)

Und "rate" sollte deutlich machen was ich meine was hier im Thread geschieht, statt ein Makro zu debuggen wird geraten was wohl helfen könnte, das merkt man an mehreren Stellen.


Gruß
Stephan
Benutzeravatar
balu
********
Beiträge: 3810
Registriert: Fr, 24.08.2007 00:28
Wohnort: Warstein

Re: Programmabsturz beim Speichern

Beitrag von balu »

Hallo Stephan,
Der Vorschlag mit dem dispatcher-Code IST ernst gemeint
Ich wollte ja nicht sagen das es ein Spaß deinerseits war, es war mir halt ein wenig Fremd.

denn .uno:save sollte versuchen Konflikte aufzulösen
Wieder was dazu gelernt. Danke.

mir hat dispatcher-Code z.B. einmal bei einem .Close geholfen was das Programm abstürzen ließ und wo ich keine Ursache fand
Wusste ich noch nicht.

Und ja, es ist hier schon eine gewisse Rätselrunde entstanden. Aber ich zumindest schaue mir schon ganz gerne den Code selber mal an, um ein kleines Gefühl dafür zu bekommen was denn da so abläuft.



Gruß
balu
Sei öfter mal ein Faultier, sag öfter mal "Ach was!" Dann kriegst du keinen Herzinfarkt, und hast ne menge Spass.

wehr rächtschraipfähler findet khan si behalden :D
erikafuchs
******
Beiträge: 690
Registriert: Di, 13.02.2007 17:38
Wohnort: Büttelborn

Re: Programmabsturz beim Speichern

Beitrag von erikafuchs »

Ein paar Antworten und neue Fragen:
Dann hatte ich mir deine Formel mal genauer angeschaut.

Code: Alles auswählen

=SUMME(C8:C29;C31;C33;C33;C35:C38;C42;C47)

Okay. Sie sah für mich im ersten Augenblick ungewohnt aus. Und ferner wird die Zelle C33 doppelt addiert, aber das ist ein anderes Thema.
Das kann ich erklären. Ich hatte ja vorübergehend in LibreOffice gearbeitet und da hatte ich in den genannten Zellen die Anzeige"#Wert", da die aufsummierten Zellen auf Zellen beziehen und diese per Formel berechnet werden. In OO geht das in LO gibt es "#Wert". Im LibreOffice Forum bekam ich den Tipp mit "=summe..." anstelle von "=Zelle1+Zelle2...". Hier der Link:
https://www.libreoffice-forum.de/viewto ... =6&t=23964
Die Aufgaben in Zelle C33 zählen doppelt.
Früher war es eine Excel-Datei, die dann in Calc weiter bearbeitet wurde und ab dann als Calc-Datei gespeichert wurde.
Balu, du hast recht, ich habe den Rechentrainer tatsächlich zunächst in Exel programmiert, habe dann aber, nach meiner Erinnerung; komplett neu mit OpenOffice angefangen. Mein Rechentraner ist jetzt weit über 10 Jahre alt, vielleicht irre ich mich, aber ich kann mich nicht erinnern, etwas aus VBA mitgenommen zu haben, lange habe ich mich da auch nicht mit beschäftigt. Ich wollte, dass meine Schüler den Rechentrainer kostenlos benutzen können und keinesfalls Microsoft Produkte kaufen oder klauen müssen.
Ich kann mich auch nicht erinnern, dass wir in unserer früheren Kommunikation das zum Thema hatten.

Lieber Stefan,
Und "rate" sollte deutlich machen was ich meine was hier im Thread geschieht, statt ein Makro zu debuggen wird geraten was wohl helfen könnte, das merkt man an mehreren Stellen.
hiermit bin ich überfordert. Kannst du mir da bitte konstruktiv weiterhelfen?
Benutzeravatar
balu
********
Beiträge: 3810
Registriert: Fr, 24.08.2007 00:28
Wohnort: Warstein

Re: Programmabsturz beim Speichern

Beitrag von balu »

Hallo Pit,

was Die Formel anging. Sie kam mir persönlich wegen lange nicht mehr genutzt komisch vor. Es war also nix gegen dich, sondern gegen mich.
Die Aufgaben in Zelle C33 zählen doppelt.
Ja dann ist doch alles klar.

aber ich kann mich nicht erinnern, etwas aus VBA mitgenommen zu haben
Es geht nicht um VBA, sondern darum dass es eine Excel-Datei '.xls' war. Und allein das kann schon Probleme machen.

habe dann aber, nach meiner Erinnerung; komplett neu mit OpenOffice angefangen.
Bist Du dir sicher?
Und warum bekomme ich bei den Zellformatvorlagen in der 'Rechentrainer_4.110.ots' haufenweise diese Vorlagennamen zu Gesicht?

Code: Alles auswählen

Excel_CondFormat_x_x_x
Das passiet meistens wenn man in Calc eine '.xls'-Datei öffnet, bearbeitet und als '.ods' speichert.

Ich kann mich auch nicht erinnern, dass wir in unserer früheren Kommunikation das zum Thema hatten.
Nun ja, vielleicht vertue ich mich auch. Kann sein das ich da vielleicht etwas durcheinander geworfen habe. Aber eins sei dir gewiss, ich wollte dich nicht angreifen.

So, und nun habe ich da eine kleinigkeit für dich.
Habe die Datei FAST neu erstellt. Sie berruht auf den eben genannten Rechentrainer (den ich von der Schul-Homepage habe). Es fehlen da aber noch folgende Dinge.
- Sie hat keine Makros und auch nicht die Dialoge. (*)
- Sie hat keine Grafiken und keine Buttons.
- An einigen Stellen musst Du noch Feinschliff erledigen: Spalten und Zeilen ausblenden, Gruppieren und ähnliches.
- Die ein oder andere Zelle noch etwas nachformatieren.

So gesehen habe ich nur die Tabellenblätter neu erstellt. Hat mich nur so ca. 10 minuten gekostet.

(*)
In der IDE kannst Du ja Module und Dialoge Exportieren und Importieren.

Wenn Du jetzt den Rest selber machst, dann achte unbedingt darauf das Du aus den Tabellenblättern nicht direkt per "Strg" + "C" kopierst und mit "Strg" + "V" in die neue Datei einfügst. Denn dadurch besteht die Gefagr das Du dir da etwas einschlääpst was nicht sein muss.
Schau ruhig mal öfter dir die Namen für Zellformatvorlagen an, wenn dann wieder etwas mit 'Excel_CondFormat_x_x_x' zu lesen ist, ist das schlecht. Also ruhig öfters zwischendurch speichern.

Ich hoffe das ist dir eine kleine Hilfe.



Gruß
balu
Dateianhänge
Rechentrainer_Grundgerüst_Blanko_0.ods
(71.34 KiB) 68-mal heruntergeladen
Sei öfter mal ein Faultier, sag öfter mal "Ach was!" Dann kriegst du keinen Herzinfarkt, und hast ne menge Spass.

wehr rächtschraipfähler findet khan si behalden :D
Antworten