OpenOffice.info

	Dim a as new com.sun.star.util.Date
	MsgBox TypeName(a)

Servus

[quote="juetho"]Siehe dagegen [url=http://www.openoffice.org/api/docs/common/ref/com/sun/star/util/Date.html]struct Date[/url][/quote]
Und was soll der Link mir sagen? Ein Struct ist ein Objekt vom Typ Struct. Ein (Basic-)String dagegen ist kein Objekt vom Typ String, sondern ein String.
[code] Dim a as new com.sun.star.util.Date
MsgBox TypeName(a)[/code]
[quote="juetho"]In OOP sind sowieso alles Objekte[/quote]
Das gilt vielleicht für eine handvoll Programmiersprachen und keine davon steht meines Wissens nach in irgendeiner Verbindung zu OOo.
[quote="juetho"]Aber noch länger müssen wir uns wohl nicht über Begriffe streiten[/quote]
Meine Absicht ist nicht, zu streiten, sondern Dein Missverständnis aufzuklären, das Fass hast Du aufgemacht ;)

[quote="DPunch"]Date ist weder ein Struct noch ein String, sondern ein eigenständiger Datentyp, so wie com.sun.star.util.Date ein Objekt ist.[/quote]
Siehe dagegen [url=http://www.openoffice.org/api/docs/common/ref/com/sun/star/util/Date.html]struct Date[/url]. In OOP sind sowieso alles Objekte. (Aber noch länger müssen wir uns wohl nicht über Begriffe streiten. :) ) Jürgen

Servus

[quote="juetho"]Wenn in Xray ein Datum als Typ=date und Wert=20120927 angezeigt wird, hatte ich diesen Wert nicht als Struct (und erst recht nicht als String), sondern als einen eigenständigen Typ interpretiert.[/quote]
Date ist weder ein Struct noch ein String, sondern ein eigenständiger Datentyp, so wie com.sun.star.util.Date ein Objekt ist.
Die updateDate-Anweisung erfordert dabei letzteres.

Das ist damit eine weitere Erklärung für meine Verwirrung: Ich habe Date/Datetime als eigenständigen Datentyp kennengelernt (der auf Zahlen basiert), und zwar sowohl bei Datenbanken als auch bei Programmiersprachen (Delphi, C# bzw. .NET). Damit kann es ebenfalls Probleme mit den String-Darstellungen geben; aber ein String ist eben kein Datum. Wenn in Xray ein Datum als Typ=date und Wert=20120927 angezeigt wird, hatte ich diesen Wert nicht als Struct (und erst recht nicht als String), sondern als einen eigenständigen Typ interpretiert. Aber jetzt weiß ich Bescheid, danke nochmals! Jürgen

dateStruct.Year & "-" & dateStruct.Month & "-" & dateStruct.Day

Servus

[quote="F3K Total"]die Sache mit den Daten (Mehrzahl von Datum) ... ist doch immer wieder eine Freude, es gibt einfach zuviele verschiedene Formate.
Der Clou ist ja, dass man z.B. die Datumsspalte einer DB-Tabelle sowohl mit [color=#0040FF]updateDate[/color] und einem wie oben gearteten Date-Struct befüllen kann, als auch z.B. mit einem [color=#0040FF]updateString[/color] ala '2012-10-31'.[/quote]
Letztendlich ist die Möglichkeit, das Datumsfeld auch per "updateDate" mit einem Date-Struct befüllen zu können, eine Komfortfunktion, die genau diese "Freude" mit den Datumsformaten lindern soll.
Da vermutlich nicht ein einziges DBMS mit diesem Date-Struct umgehen kann, wird daraus vor der Weitergabe an die Datenbank sowieso ein zum verlangten Datumsformat kompatibler String generiert, was Dir eben den Ärger mit den verschiedenen Formaten erspart.
Intern wird aus der updateDate-Anweisung also eine updateString-Anweisung mit einem Wert ala
[code]dateStruct.Year & "-" & dateStruct.Month & "-" & dateStruct.Day[/code]
Daher auch die Fehlermeldung "Objektvariable nicht belegt", wenn man der updateDate-Anweisung eine Variable übergibt, die eine der Properties Year/Month/Day nicht kennt, wie z.B. einen einfachen String oder eine Zahl.

soldDate = CDate(oEvent.Source.BoundField.String)
snewDate = CDate(oEvent.Source.Text)

  oForm.updateDate(6, oldDate)
  oForm.updateRow

So, ich habe jetzt die Vorschläge beim [b]Ereignis "Vor dem Aktualisieren" [/b]umgesetzt, Sowohl oldDate als auch newDate hole ich als Strings und übertrage die Werte (wie von F3K vorgeschlagen) in date-Strukturen:
[code]soldDate = CDate(oEvent.Source.BoundField.String)
snewDate = CDate(oEvent.Source.Text)[/code]
Das "Änderung verwerfen" im else-Zweig am Ende habe ich so gelöst:
[code] oForm.updateDate(6, oldDate)
oForm.updateRow[/code]
Alles funktioniert wunschgemäß; ich hoffe, dass nicht später irgendwelche unerwünschten Nebenwirkungen auftauchen. Nochmals herzlichen Dank für die Unterstützung! Jürgen

[quote="DPunch"]Wieso bist Du so sehr davon überzeugt, dass oForm nicht belegt sein soll?[/quote]
Bei meinen Versuchen hatte ich verschiedene Anweisungen aufgeteilt und einzeln abgefragt (mit msgBox oder xray oder Debugger). Weil die beiden "Datümer" angezeigt wurden, habe ich vermutlich oForm die Schuld gegeben.

[quote](newDate ist kein Date-Struct).[/quote]
Einige Anzeigen in xray und Formulierungen in der OO-Hilfe ließen mich davon ausgehen, dass Date ein eigenständiger numerischer Datentyp ist (was ich in der API nicht überprüft hatte). Wenn es sich dagegen immer um ein Struct handelt, muss ich natürlich anders vorgehen - beispielsweise mit einer dim-Anweisung wie in Riks Vorschlag.

[quote="F3K Total"][code] if msgbox ("Soll das Datum wirklich auf "+snewDate+" geändert werden",36,"Datum ändern?") = 6 then[/code][/quote]
Diese Lösung mit msgBox statt Dialog ist in der Tat einfacher. Ich hatte wohl Tomaten auf den Augen, als ich vergeblich nach einer entsprechenden msgBox-Gestaltung gesucht hatte (statt einfach in der OO-Hilfe nachzuschauen).

[quote="F3K Total"][code] oForm.updatedate(6, newDate)[/code][/quote]
Warum muss/soll updateDate im if-Zweig benutzt werden? Wenn ich die Ereignisse richtig verstehe, wird durch Fokusverlust (einem späteren Ereignis) sowieso der neue Wert übernommen. Also ist es doch nicht notwendig, diesen Wert ausdrücklich zuzuweisen, oder?
[quote="F3K Total"][code] else
nrow = oForm.row
oform.reload[/code][/quote]
reload wollte ich vermeiden (das ist einer der Auslöser für meine Lösungsversuche): In der Praxis ist das Datumsfeld, um das es hier geht, das erste Feld im Formular und wird in der Regel als erstes bearbeitet. Beim Arbeiten mit Maus könnte aber durchaus ein anderes Feld schon geändert worden sein; und diese Änderung wäre verloren. Aber wenn es keine ausdrückliche Anweisung wie oform.reset/reject oder einen Umweg gibt, muss es wohl so sein.

Recht herzlichen Dank jedenfalls euch beiden für Vorschläge, Fehlerhinweise und Erläuterungen! Gruß Jürgen

[quote="DPunch"]F3K hat Dir die vermutlich die Lösung Deiner Probleme schon mundgerecht vorgelegt[/quote]
Aber du hast es, wie schon so oft, mit zwei, drei Worten erklärt! :D
Ja, ja ... die Sache mit den Daten (Mehrzahl von Datum) ... ist doch immer wieder eine Freude, es gibt einfach zuviele verschiedene Formate.
Der Clou ist ja, dass man z.B. die Datumsspalte einer DB-Tabelle sowohl mit [color=#0040FF]updateDate[/color] und einem wie oben gearteten Date-Struct befüllen kann, als auch z.B. mit einem [color=#0040FF]updateString[/color] ala '2012-10-31'.

Gruß Rik

newDate.Year

oForm.updateDate(6, oldDate)

Servus

Wieso bist Du so sehr davon überzeugt, dass oForm nicht belegt sein soll?

Ich sehe z.B. in Deinem Code ein
[code]newDate.Year[/code]
obwohl die Objektvariable "newDate.Year" nicht belegt ist (newDate ist kein Date-Struct).
Ich sehe in Deinem else-Zweig ein
[code]oForm.updateDate(6, oldDate)[/code]
obwohl oldDate kein Date-Struct ist.

Beides Fehler im Quellcode, die die beschriebene Fehlermeldung hervorrufen.

Nachtrag: F3K hat Dir die vermutlich die Lösung Deiner Probleme schon mundgerecht vorgelegt 8)

Sub S_checkmodified (oEvent)
    dim newdate as new com.sun.star.util.Date

    oField = oEvent.Source
    oForm = oField.Parent
    snewdate = CDate(oField.Text)
    
    newDate.year = year(snewdate)
    newDate.month = month(snewdate)
    newDate.day = day(CDate(snewdate)

    if msgbox ("Soll das Datum wirklich auf "+snewDate+" geändert werden",36,"Datum ändern?") = 6 then
        oForm.updatedate(6, newDate)
        oForm.updaterow
    else
        nrow = oForm.row
        oform.reload
        oform.absolute(nrow)
    endif

end sub

Hallo Jürgen,
dieses Makro scheint auf "vor dem Aktualisieren" zu funzen.
[code]Sub S_checkmodified (oEvent)
dim newdate as new com.sun.star.util.Date

oField = oEvent.Source
oForm = oField.Parent
snewdate = CDate(oField.Text)

newDate.year = year(snewdate)
newDate.month = month(snewdate)
newDate.day = day(CDate(snewdate)

if msgbox ("Soll das Datum wirklich auf "+snewDate+" geändert werden",36,"Datum ändern?") = 6 then
oForm.updatedate(6, newDate)
oForm.updaterow
else
nrow = oForm.row
oform.reload
oform.absolute(nrow)
endif

end sub[/code]
Gruß R

dim bchange as Boolean
oForm = oEvent.Source.Parent
bchange = ...    ' einfache Prüfung liefert hier true oder false
oldDate = CDate(oEvent.Source.BoundField.String)    ' die beiden Vergleichswerte
newDate = CDate(oEvent.Source.Text)
rem bei manchen Situationen Rückfrage über Dialog
if not bchange then
  oDlgDesc = globalscope.DialogLibraries.Standard.dlgConfirm
  dlg = CreateUnoDialog( oDlgDesc )
  bchange = dlg.execute       ' OK = ja, andernfalls = Nein
end if

if bchange then     ' Änderung tatsächlich ausführen
  oForm.updateInt(3, newDate.Year)
   ...  
else
  rem Änderung rückgängig machen
' xray oEvent.Source.BoundField
' xray oldDate
' oEvent.Source.BoundField.updateDate(oldDate)
  oForm.updateDate(6, oldDate)
end if

Nach der Eingabe in einem Datumsfeld (an eine Tabelle gebunden) möchte ich prüfen, ob die Eingabe zulässig ist. Im Zweifelsfall wird der Anwender über einen Dialog gefragt: "Wollen Sie wirklich diese Änderung vornehmen?" Wenn ja, wird die Eingabe übernommen, andernfalls soll sie verworfen werden und der bisherige Feldinhalt unverändert bleiben.

Ich habe die Prüfung an das Ereignis "Vor dem Aktualisieren" gebunden, weil ich dort beide Werte (vorher und nachher) abfragen kann - siehe [url=http://de.openoffice.info/viewtopic.php?f=18&t=55392]"ist modifiziert" prüfen[/url]. Das Makro sieht (verkürzt) so aus:
[code]dim bchange as Boolean
oForm = oEvent.Source.Parent
bchange = ... ' einfache Prüfung liefert hier true oder false
oldDate = CDate(oEvent.Source.BoundField.String) ' die beiden Vergleichswerte
newDate = CDate(oEvent.Source.Text)
rem bei manchen Situationen Rückfrage über Dialog
if not bchange then
oDlgDesc = globalscope.DialogLibraries.Standard.dlgConfirm
dlg = CreateUnoDialog( oDlgDesc )
bchange = dlg.execute ' OK = ja, andernfalls = Nein
end if

if bchange then ' Änderung tatsächlich ausführen
oForm.updateInt(3, newDate.Year)
...
else
rem Änderung rückgängig machen
' xray oEvent.Source.BoundField
' xray oldDate
' oEvent.Source.BoundField.updateDate(oldDate)
oForm.updateDate(6, oldDate)
end if[/code]
Alles, was ich im else-Zweig versuche, führt zum Basic-Laufzeitfehler "Objektvariable nicht belegt". Einzelprüfungen über xray oder den Basic-Debugger zeigen, dass alle diese Variablen zur Verfügung stehen; vermutlich die Fehlermeldung falsch. Ich könnte verstehen, dass updateXXX im Ereignis "Vor dem Aktualisieren" nicht möglich ist. Ich finde aber keine Methode, die eine Änderung nur für diese einzelne Spalte (im aktuellen Datensatz) verhindert.

Was tun? Jürgen

[u]Nachtrag:[/u] Auch im if-Zweig wird oForm.updateXXX benötigt. Ich habe jetzt festgestellt, dass diese Änderungen am gleichen Fehler scheitern. Als ich den Dialog noch nicht eingebaut hatte, hatte es funktioniert. Offensichtlich bringt der Dialog den Zugriff auf oForm durcheinander.

[u]Nachtrag 2:[/u] Wenn es doch so einfach wäre. Es sieht so aus, als ob doch nicht der Dialog schuld wäre, sondern das Ereignis. Ich werde wohl doch auf "Fokusverlust" zurückgehen müssen und auf die genaue Anzeige (Zustand alt und neu) verzichten.

[u]Nachtrag 3:[/u] Ich verzweifle noch. Jetzt bin ich bei "Fokusverlust" ohne Dialog - und oForm ist auch im if-Zweig nicht mehr belegt. [i]Das war für heute mein letzter Versuch. [/i] :cry:

Aber vielleicht gibt es eine andere, saubere Lösung.