Base-"Datensatz speichern"-Button (Diskettenknopf) per Makro abfragen?

[Freischreiber]

Hallo gogo,

vielen Dank! Es sieht jetzt so aus und funktioniert auch, wenn nicht nur der bestehende Datensatz ergänzt, sondern komplett neu ist:

Code: Alles auswählen

Sub BuchungAuftragsFormular(oEvent)
	oformAuftraege = oEvent.Source.Model.Parent 'Braucht nur ein Parent-Formular, egal wie es heißt!
	stAuftragID = oformAuftraege.getString(oformAuftraege.findcolumn("Auftragnr"))
	oformAuftrag = ThisDatabaseDocument.getformdocuments.GetByName("f-Auftrag")
	oformAuftrag.open
	oformAuftrag = oformAuftrag.Component.drawpage.forms(0)

	'Ergänzung um Sicherheitsfragen
	DIM intFrage As Integer
	with oFormAuftrag
   		if .ismodified then
   			intFrage = MsgBox("Der angezeigte Datensatz wurde geändert. Änderungen speichern?", MB_ICONQUESTION + MB_YESNO + MB_DEFBUTTON1, "Makro BuchungAuftragsFormular") 
			'MB_DEFBUTTON1 macht das Ja zur vorgeschlagenen Antwort.
      			if intFrage = IDYES then
         			if .isnew then
            			.insertrow
         				else
            			.updaterow
        			end if
      			end if
   		end if
	end with
	'Ergänzung Ende. 
	
	oformAuftrag.Filter = "Auftragnr = '"+stAuftragID+"'" 
	oFormAuftrag.reload
End Sub

ABER: Ich glaube wirklich, da ist ein Bug in Base! Denn Änderungen in einem Formularfeld eines bestehenden Datensatzes, z. B. da steht der Name "Müller" und ich ergänze ihn um "-Lüdenscheid" bringen unten sofort das Diskettensymbol zum Leuchten, auch solange der Cursor noch im Feld ist.

Auch wenn ich in diesem Zustand mit den Base-Buttons in einen anderen Datensatz springe, werde ich gefragt, ob Änderungen gespeichert werden sollen (von Base selbst). Die werden dann auch gespeichert.

Aber diese Änderungen lösen vor dem Verlassen des Textfelds kein ismodified=true aus! Das Makro fragt nicht und speichert nicht. Wenn drei Textfelder geändert werden und der Cursor steht noch im dritten, werde ich gefragt, aber die Änderung im dritten Feld wird nicht gespeichert.

Also nochmals vielen Dank für die Makrohilfe. Aber zu Base kann ich nur sagen: ich bin entsetzt.

Gruß
Freischreiber

[gogo]

"Bug" ist vielleicht etwas zu hoch, Dir ist evtl. folgendes passiert:
Base ermittelt in bestimmten Situationen NICHT, ob in einem Formularfeld etwas neu geschrieben wurde, wenn man vom Feld aus direkt auf das Diskettensymbol klickt.
Ich habe das mal beobachtet, wenn man in einem Datumsfeld das Datum per Dropdown eingibt. Dann steht zwar das Datum drin, wenn man aber nach dem Klick auf den gewünschten Tag des Datum-Dropdownfeldes direkt auf das Diskettensymbol klickt, wird nicht das angezeigte Datum sondern das was vorher in dem Feld stand gespeichert.
ein: oForm.getbyname("MeinDatumsfeld").commit löst das Problem, oder man gewöhnt sich an, nach dem Einstellen das Datums in irgendein anderes Formularfeld zu klicken. Dann findet das Commit richtig statt. Oder man hängt so ein Makro an die Eigenschaft "Text modifiziert":

Code: Alles auswählen

sub CommitFormFeld(oEvent)
on error resume next
oEvent.Source.Model.commit
end sub

das ist aber mühsam.

[Freischreiber]

Hallo gogo,

jetzt hab ich mal eine kleine Datei mit interner DB gebaut, um zu testen, ob es nur mit externen DBs passiert. Aber hier ist es auch so, daß man Änderungen am Text vornehmen kann und sie werden erst gespeichert, wenn man z. B. per Tabulatortaste das Textfeld verlassen hat.

Neue Datenbank.odb.zip

Nur umbenannt. ".zip" einfach weglöschen.

(13 KiB) 220-mal heruntergeladen

(Hier funktioniert das Speichern bei neuen Datensätzen nicht. Ich finde auf die Schnelle nicht heraus, warum)

Ob Bug oder nicht, kann ich nicht beurteilen. Aber seltsam finde ich es schon. Das Diskettensymbol leuchtet bei Änderungen sofort auf, aber ismodified wird nicht true.

Gruß
Freischreiber

[gogo]

unter 5.1.4.2 kann ich das nicht bestätigen - ich werd's morgen mal mit einer 4.x Version probieren

[gogo]

ah ... ich hatte mich verlesen ...
Das Problem ist, dass die .ismodified-Eigenschaft des Formluars ein bisschen (~0,12 Sekunden) braucht um auf "true" zu springen. Ich hab' in Dein Makro das entsprechend eingebaut:

Code: Alles auswählen

Sub BuchungAuftragsFormular(oEvent)
   oformAuftrag = oEvent.Source.Model.Parent 'Braucht nur ein Parent-Formular, egal wie es heißt!
   'Ergänzung um Sicherheitsfragen
   DIM intFrage As Integer

with oformAuftrag
	' Entweder: ------------------------------
	wait 200
	' oder:  ---------------------------------
	'   Dim i
	'   i=0
	'	Do While NOT .ismodified 
	'		i=i+1
	'		wait 10 '... 1/100 Sekunde warten
	'		If i > 200 Then Exit Do '... Schleife nach ~2 Sekunde beenden
	'	Loop
	'	if i<201 AND i>0 then msgbox "Wartezeit = " & i/10 & " Sekunden"
	' --------------------- ... Ende "oder" --
	if .ismodified then
	intFrage = MsgBox("Der angezeigte Datensatz wurde geändert. Änderungen speichern?", _
		MB_ICONQUESTION + MB_YESNO + MB_DEFBUTTON1, "Makro BuchungAuftragsFormular")
		'MB_DEFBUTTON1 macht das Ja zur vorgeschlagenen Antwort.
		if intFrage = IDYES Then
			if .isnew Then
				.insertrow
			else
				.updaterow
			end If
		Else
			if .isnew Then
				msgbox "Das Einfügen eines neuen Datensatzes wurde abgebrochen! " & _
						"Die Änderungen werden noch angezeigt Bitte ggf. mit dem Button " & _
						"'Rückgängig: Dateneingabe' die veränderten Felder zurücksetzen!"
			else
				.cancelRowUpdates 
				IF .ismodified then
					msgbox "Nichts gespeichert! Die Änderungen werden noch angezeigt! " & _
							"Bitte ggf. mit dem Button 'Rückgängig: Dateneingabe' die " & _
							"Originaldaten wiederherstellen!"
				Else
					msgbox "Nichts gespeichert! Die Änderungen wurden rückgängig gemacht!"
				End If
			End if
		end if
	end if
end with
   'Ergänzung Ende.
'   oFormAuftrag.reload
End Sub

sub CommitFormFeld(oEvent)
on error resume next
oEvent.Source.Model.commit
end sub

Auf das Formular kannst Du auch besser über das oEvent referenzieren - die .open-Methode ist umständlich und das Formular ist ja schon geöffnet
Den Fall des "Nicht-Speichern" habe ich etwas ausgebaut, Du kannst dann genau sehen ob und wann das Diskettensymbol wieder ausgegraut ist.
oFormAuftrag.reload führt nur zu Fehlern, falls der Filter im Formular nicht 100%ig passt. Der Befehl lädt Daten neu und springt zum ersten Datensatz (und nicht zum aktuellen)!

Das Warten auf .ismodified kannst Du komplett überspringen, wenn Du an die "Text-geändert"-Eigenschaft jedes veränderbaren Feldes das Makro CommitFormFeld bindest. Damit werden die Änderungen zur Laufzeit "übergeben" und die ismodified-Eigenschaft des Formulars auf true gesetzt!

[Freischreiber]

Hallo gogo,

ab wann laufen die 0,12 Sekunden? Erst mit Makrostart? Weil, die Änderungen im Formular sind ja schon längst gemacht, wenn das Makro startet...

Ist es richtig, daß als minimale Änderung es ausreicht, mein Makro zu ergänzen um die Zeile
with oformAuftrag
wait 200
?

Das open brauche ich wohl, das Makro soll von einem anderen Formular aus das Auftragsblatt aufrufen, manchmal ist das Auftragsblatt noch nicht geöffnet, manchmal schon. (Und manchmal eben mit ungespeicherten Änderungen).

"oFormAuftrag.reload" lieber ersatzlos streichen?

Gruß
Freischreiber

[gogo]

ab wann laufen die 0,12 Sekunden? Erst mit Makrostart?

ja, entweder Makrostart, oder ab Objektzuweisung

Ist es richtig, daß als minimale Änderung es ausreicht, mein Makro zu ergänzen um die Zeile
with oformAuftrag
wait 200

ja, das müsste ausreichend sein, zumindest bei der simplen Beispieldatenbank. Ich hab's ~5 mal probiert, es waren immer Zeiten zwischen 0,1 und 0,12 Sekunden. Aber speziell in dem Fall:

... das Makro soll von einem anderen Formular aus das Auftragsblatt aufrufen, manchmal ist das Auftragsblatt noch nicht geöffnet, manchmal schon. (Und manchmal eben mit ungespeicherten Änderungen).

würde ich immer die Variante mit dem "CommitFormFeld"-Makro vorziehen. Sie ist schlicht und ergreifend sicherer.

"oFormAuftrag.reload" lieber ersatzlos streichen?

Das liegt im Wesentlichen am Filter den Du verwendest. Wichtig ist, dass dem Benutzer nach den Messageboxen wieder der richtige Datensatz angezeigt wird. Wenn Du nur einen Datensatz anzeigen lässt, ist das reload ok, so lange er nach dem Speichern auch noch der für den Benutzer richtige Satz ist! Spätestens beim Erfassen neuer Datensätze wird das schwierig, denn wie soll denn Dein Filter 100%ig sicher wissen wie er einen Datensatz anzeigen soll, den es evtl. noch gar nicht gibt. Im Falle des Speicherns ist das "kein" Probelm. Da kannst Du ja einen eindeutigen Schlüssel im Satz abfragen und dann den Filter neu exakt für den einen Datensatz setzen.
Im Falle eines Abbruchs war das Formular aber evtl auf Datensatz 3 von 5. Nach dem Reload steht es auf 1 von 5.
Deswegen habe ich die Sektion mit dem ".cancelRowUpdates" erweitert, das ist nichts anderes als ein Klick auf das "Rückgängig: Dateneingabe"-Symbol in der Navigationsleiste. Ich habe die Erfahrung gemacht, dass User sich 1-2 maximal 3 Symbole aus solchen Navigationsleisten aktiv merken können/wollen. Wenn man beim Speichern aber darauf hinweist lernen sie's leichter. Das Hirn scheint dann im "Hoppla-Das-Ist-Keine-Routine"-Modus zu sein

[Freischreiber]

Es funktioniert nicht, weder das einfache wait noch die Schleife. (keine Meldung aus der Schleife)
Das Formular wartet einfach zwei Sekunden und filtert immer noch ohne Rückfrage die Änderungen weg.

Das mit dem commit ist fast nicht machbar, es sind ziemlich viele Felder in dem Formular.

Nachtrag: Bei der Beispieldatenbank oben kann ich es nachvollziehen, da findet Base nach ca. 0,4 Sekunden die Änderung und speichert sie.
Aber bei meiner externen DB habe ich die Schleife jetzt auf 3000 gestellt (30 Sekunden) und es passiert nichts...

[gogo]

Bei mir schon - falls die Konstruktion so stimmt.
Öffne nach dem Start das Formular "Startform", ein Klick auf den Button öffnet dann das 2. Formular.
Anmerkung: ich hab' die Zuweisung des Formulars codetechnisch geändert

Code: Alles auswählen

oAuftragWriterDoc = ThisDatabaseDocument.getformdocuments.GetByName("f-Tabelle1").Open
oformAuftrag = oAuftragWriterDoc.DrawPage.Forms.getByName("MainForm")

[Freischreiber]

Bei mir schon - falls die Konstruktion so stimmt.

Dann liegt es bei mir vielleicht an der gesplitteten DB oder an meiner älteren LO-Version...