Calc-Freeze nach exit sub im dialog

[Wolfgang Hor]

Liebe LO-Community!

Habe ein seltsames Problem mit einem Calc makro, bei dem ich nicht weiß, ob es sich schlichtweg um mangelnde Programmierkenntnisse (oder schlampiges Programmieren?) oder einen Bug handelt? Vielleicht könnt ihr ja was zur Erhellung beitragen? Ich arbeite mit LO 6.3.5.2 (x64) unter Windows 7.
Bin zwar kein totaler Neuling im Makro-Schreiben, aber weit entfernt von tiefergehendem Wissen. Ich bastle an einer Calc-Datei, die das Erstellen von Figuren für ein selbstgemachtes Rollenspiel vereinfachen soll.
Teilweise geht das über Dialoge. Und da taucht ein (mir) neues Problem auf, das ich nicht in den Griff kriege.
In einem Dialog gibt es zwei ComboBoxen und einen CommandButton für "weiter", der die ausgewählten Werte in die Tabelle schreiben soll. Das Sub des CommandButtons soll nur dann bis zum Ende laufen, wenn in beiden ComboBoxen ein Wert ausgewählt wurde, ansonsten (wenn dort zB "wählen" steht), soll eine Msgbox darauf hinweisen, dass noch nicht alle Auswahlen getroffen sind - mit "exit sub" soll abgebrochen werden. Das funktioniert. Und dann soll ein weiterer Dialog gestartet werden, in dem eine andere Auswahl getroffen werden soll (wieder mit einer ComboBox und einem ok-Button wie oben beschrieben). Und hier gibt es das Problem: Manchmal, wenn keine Auswahl getroffen wurde, friert Calc nach Bestätigung der MsgBox ein und kann nur mehr über den Taskmanager beendet werden. Selten, aber doch, friert Calc auch schon beim ersten Dialog ein. Seltsam ist eben, dass das nur manchmal geschieht, manchmal erst nach dem vierten oder fünften Test, manchmal auch gleich beim ersten Mal. Es tauchen keine Fehlermeldungen auf.
Ohne die "exit sub"-Anweisungen funktioniert alles einwandfrei. Was mache ich falsch?
Ich habe das Problem in einer Datei nachgestellt, da taucht es auch auf, genau wie eben beschrieben. Ich füge die Datei an.
Es würde mich freuen, wenn mir jemand weiterhelfen könnte.
LG Wolfgang

[craig]

Hallo Wolfgang,

Code: Alles auswählen

Option Explicit

gehört immer in die erste Zeile, oberhalb aller Variablen.

Grund:
Option Explicit prüft alle Variablen auf korrekte Deklaration, Schreibweise, usw.
Wenn nun eine Variable oberhalb von O...E... steht, dann wird diese nicht geprüft
und weitere Fehler sind nicht ausgeschlossen.

Ich konnte den Fehler reproduzieren und denke der Fehler
liegt an der IF-Anweisung des zweiten Dialogs.
Du schreibst "Exit Sub", aber der Dialog ist immer noch aktiv und damit kommt der Interpreter nicht klar.
Siehe dazu die Änderung von mir im nachfolgenden Codeabschnitt:
REM Erst den Dialog beenden
.endexecute
REM dann die Routine beenden
exit sub

Hier der von mir geänderte Code zum Modul "d_2_start"

Code: Alles auswählen

rem ____________________________________

Option explicit

dim t1 as object
dim oDia2 as object
dim daten_c as object
dim oData_c as variant

sub dialog_2_starten()

t1 = thiscomponent.sheets.getbyname("Tabelle1")
dim i as integer

'Code for initiating and showing the dialog    '   
dialoglibraries.loadlibrary("Standard")
oDia2 = CreateUnoDialog(DialogLibraries.Standard.dialog_2)

with oDia2

	'vorbereitung des dialogs
	daten_c = .getcontrol("ComboBox1")
	
	'combo daten_c füllen
	daten_c.text = "wählen"
	'Read the data list from cell range into a variant array '
	oData_c = t1.getCellRangeByName("J2:J7").DataArray 'dort stehen die daten, die eingelesen wd sollen
	For i = 0 to 5
		daten_c.addItem(oData_c(i)(0) ,i)
	Next i
	
	.execute
	
end with

end sub

rem _____________________________________________

sub dialog_2_ok

dim wahl_c as string

t1 = thiscomponent.sheets.getbyname("Tabelle1")

with oDia2
	
	daten_c = .getcontrol("ComboBox1")
	
	wahl_c = daten_c.gettext
	
	if wahl_c = "wählen" then
		msgbox("Zuerst auswählen!")
REM Erst den Dialog beenden		
			.endexecute
REM dann die Routine beenden
		exit sub
	end if
	
	t1.getcellrangebyname("H9").string = wahl_c
	
	.endexecute
	
end with

end sub

Beachte das "Option Explicit " in Deinem ersten Modul ebenfalls ganz nach oben gesetzt werden muss..

[Wolfgang Hor]

Hallo Craig,

vielen Dank, dass du dir das angesehen hast. Danke auch für den Hinweis auf option explicit! Werde das gleich ändern!
Zu deinem Vorschlag, den Dialog zuerst zu schließen:
Die msgbox ist deswegen eingebaut, damit der ganze Ablauf nicht weitergehen kann, ohne dass eine Auswahl getroffen ist. Der User sollte daher gleich im Dialog, wo er vergessen hat, etwas auszuwählen, weitermachen können. Andernfalls müsste er ja die ganze Prozedur des Durchlaufens wieder von vorne beginnen. Mühsam.
Abgesehen davon: Hab in der Zwischenzeit ein bisschen weiter herumprobiert und herausgefunden: Das Einfrieren liegt nicht an "exit sub", sondern taucht immer dann auf, wenn man von der msgbox zurückkehrt zum Dialog. Ich hatte probehalber die If-Anweisung im 2. Dialog umgedreht (wenn <>"wählen", dann wird die Auswahl in die Tabelle geschrieben und der Dialog beendet, andernfalls taucht die msgbox auf, und zwar vorm Ende vom sub - wodurch ich mir das "exit sub" erspare.) Hat aber eben nichts gebracht, das Einfrieren passiert erneut.
Nebenbei: Wie schreibst du Code hier ins Forum?

[craig]

Hallo Wolfgang,

Die msgbox ist deswegen eingebaut, damit der ganze Ablauf nicht weitergehen kann, ohne dass eine Auswahl getroffen ist. Der User sollte daher gleich im Dialog, wo er vergessen hat, etwas auszuwählen, weitermachen können. Andernfalls müsste er ja die ganze Prozedur des Durchlaufens wieder von vorne beginnen. Mühsam.

Ja hast recht. Habe ich nicht bedacht.
Nun habe ich Dein ürspüngliches Makro in folgenden Officeversionen getestet:

• AOO 4.1.6 --> funktioniert ohne Probleme
• LibO 6.2.5.2 portabel --> friert ein
• LibO LO 6.3.4.2 (x64) --> friert ein
• 7.0.0.0.alpha0+ (x64) --> friert ein

Ursache des Einfrierens ist mir unerklärlich, habe den Code
auch an verschiedenen Stellen mal abgeändert, jedoch ohne Erfolg.

Dann erinnerte ich mich an diesen Bug:
https://bugs.documentfoundation.org/sho ... ?id=124628
Das heißt ich habe den Command-Buttons in Deinen Dialogen ein anderes
Event zugewiesen, aber auch dass brachte keinen Erfolg.
Event "Aktion bestätigen"
ausgetauscht gegen
Event "Maustaste losgelassen"

Das Einfrieren liegt nicht an "exit sub", sondern taucht immer dann auf, wenn man von der msgbox zurückkehrt zum Dialog.

Das kann ich nicht zu 100% bestätigen, denn bei mir friert LibO
zuweilen ein, wenn der erste Dialog geschlossen wird.

Warum Dein Code in AOO funktioniert und in LibO nicht, habe ich nicht herausgefunden.
Auch nicht ob es sich um einen Bug handelt.

Im Augenblick bin ich am Ende meines Wissens , vielleicht findet sich
noch ein anderer Helfer der den entscheidenden HInweis liefert.

Nebenbei: Wie schreibst du Code hier ins Forum?

Siehe hier:

BB-Code Tags.odt

(80.58 KiB) 235-mal heruntergeladen

[Wolfgang Hor]

Hi Craig,

interessante Infos von dir! Danke! Dann werd ich mal open office wieder installieren, auch wenn ich eigtl. nicht vorhatte, zurückzukehren. Aber was soll´s?
Hab einige Testdurchläufe mit unterschiedlichen Variationen des Problems gemacht. Mir scheint, das Prob taucht erst auf, wenn
- Comboboxen beteiligt sind (CommandButtons scheinen kein Prob zu sein)
- 2 Dialoge in Folge (als Kette sozusagen) aufgerufen werden (1 ist auch kein Prob)
- man von einer msgbox zurück zum Dialog kommt
Mir ist aufgefallen, dass der Speicherverbrauch lt. Taskmanager vor dem/beim Freeze manchmal deutlich steigt (von ca. 67.000k normal auf 120.000k, aber ich hatte auch schon freezes bei 67). Ob das was bedeutet, außer dass eben was nicht passt, entzieht sich allerdings meiner Kenntnis!?

Wie auch immer, danke jedenfalls für deine Mühe und die code-tags!!
Falls du / oder jemand noch weitertüfteln will nach/mit meinen Versuchen, ich hab das Dok angehängt (und mich bemüht, gut zu dokumentieren, was ich gemacht hab...)
Grüße Wolfgang...gesund bleiben!