Datenstruktur für Kalender

Listing

Ich suche eine gute Datenstruktur für einen Kalender mit Timerfunktion (einmalig alarm geben oder jede sekunde/minute/stunde/tag/woche/monat/jahr), mit der ich auch die WinApis benutzen kann.

Leider muss ich bei Strukturen wie time_t alles mögliche wie

int tm_wday;     /* Tage seit Sonntag (Wochentag) - [0,6] */
   int tm_mday;     /* Tag des Monats - [1,31] */

ausfüllen, das ich nicht ohne weiteres weiß.

Gibt es nicht eine einfache Struktur, mit der ich nur den Tag, stunde, sekunde, und jahr eingeben muss und bei der ich den wochentag, monat, etc. automatisch kriege? Es ist sehr umständlich alles neu zu berechnen. Oder gibt es da bereits eine gute Lösung?

Es sollte dann auch möglich sein Differenzen der Zeit zu berechnen und die Zeitspanne zu vergrößern (etwa eine Stunde oder einen Tag dazuzuaddieren)

Welche API's und Strukturen sollte ich da am besten verwenden?
Es kann auch eine bereits existierende Klasse sein.

Danke
Listing

CStern

Hallo,

du kannst beruhigt sein: Es ist alles schon da und so da, dass Du sehr viel damit anfangen kannst. Diese Funktionen schlummern in der Oleaut32.dll und Du kannst sie nutzen in:

INT VariantTimeToSystemTime( 
  double  vtime,              
  LPSYSTEMTIME  lpSystemTime  
);

das Gegenstück dazu:

INT SystemTimeToVariantTime(
  LPSYSTEMTIME  lpSystemTime,  
  double        *pvtime           
);

Snipp* ...

typedef struct _SYSTEMTIME {  
  WORD wYear;  
  WORD wMonth;  
  WORD wDayOfWeek;  
  WORD wDay;  
  WORD wHour;  
  WORD wMinute;  
  WORD wSecond;  
  WORD wMilliseconds;
} SYSTEMTIME, *PSYSTEMTIME;

Noch fragen?

Vielleicht den double-Value? Der hat vier Stellen vor dem Komma und vier Stellen nach dem Komma. Die vier Stellen vor dem Komma repräsentieren die Tage nach dem 01.01.1972 bis heute und die vier Nachkommastellen einen Wert von verstrichenen Sekunden seit 00:00:00 Uhr des Tages der Vorkommastelle. wMilliseconds sind Makulatur. Klar das man mit dem Double mathematisches anfangen kann und das Resultat dann immer in korrektem Datum wieder zurückwandelt und Umgekehrt ein Datum zu dem Double-Value.
Genauso wird in VB/VBA Datum gehandelt und Funktionen wie DateDiff und DateAdd zum Beispiel gebaut.

Alternativ kann es die gute alte "time.h", aber nicht so komfortabel.

Listing

Vielen dank

Martin Richter

Diese VariantTime auf dei CStern hinweist wird komplett durch COleDateTime gekapselt und ist sehr flexibel und einfach zu nutzen.

Listing

Gibt es auch eine Möglichkeit ein Datum bzw. eine Zeit anzugeben und den nächstmöglichen Zeitpunkt (in der Zukunft) zu bekommen an dem das erfüllt ist?

Ich möchte z.B. folgendes machen

ScheduleUpdates(TYPE_RETRIGGER,DAY_MONDAY, 4 /* Hour */, 31 /* Seconds */);

oder

ScheduleUpdates(TYPE_RETRIGGER,MONTH_JANUARY, DAY_MONDAY, 4 /* Hour */, 31 /* Seconds */);

Wenn das UpdateEvent dann getriggert wird, will ich die Funktion mit den gleichen Parametern erneut aufrufen, um das nächste event aufzurufen falls der Typ "TYPE_RETRIGGER" ist.

Gruß
Listing

Martin Richter

Mit den arithmetischen Funktionen von COleDateTime/COleDateTimeSpan ist das doch nicht so schwieirg oder? Die Memberfunktionen erlauben Dir auch zusätzlich Zugriff auf Wochentag und KW...

Brutforce
- Inkrementeiere Datum bis Datum stimmt
- Imkrementiere Uhrzeit bios Uhrzeit stimmt

Das Inkrement kann bei Montat und Jahr auch um einen großen Wert vorgesetzt werden (z.b. 28 Tage, 364 Tage).

Listing

Du meinst ich soll den

double  vtime

so lange erhöhen, bis der LPSYSTEMTIME struct die gewünschte Zeit anzeigt

Wenn ja hört sich das gut an, auch wenn es ein bisschen resourcenlastiger als das reine Berechnen ist.

Wenn das alles so stimmt hätte ich nurnoch das Problem mit der Zeitzone.
Weil eigentlich brauche ich ja für einen Kalender nicht die Systemzeit sondern die Userzeit oder irre ich mich?

Gruß
Listing

Martin Richter

1. Mit COleDateTime ist das doch einfach.
2. Du musst doch nur den Inkrement intelligent wählen. VOn einem Datum:
- Nächste Woche +7
- Nächster Monat, Montag, +28, weiter mit +1 bis Monat sich geändert hat und Montag erreicht wird.

Das ist doch nicht Ressourcen intensiv!

Listing

Jo ok :xmas1:
Hatte mir der Begriff Bruteforce nur suggeriert

Dankeschön

CStern

Martin Richter schrieb:

Diese VariantTime auf dei CStern hinweist wird komplett durch COleDateTime gekapselt und ist sehr flexibel und einfach zu nutzen.

Öhm schon ... aber sind wir hier in MFC-Forum? :xmas2:
Wenn ja, muss ich ja flüchten - ich hasse MFC!

Martin Richter

CStern schrieb:

Martin Richter schrieb:

Diese VariantTime auf dei CStern hinweist wird komplett durch COleDateTime gekapselt und ist sehr flexibel und einfach zu nutzen.

Öhm schon ... aber sind wir hier in MFC-Forum? :xmas2:
Wenn ja, muss ich ja flüchten - ich hasse MFC!

Prüfe erst was Du behauptest bevor Du es schreibst

COleDateTime gehört wie CStringT seit VS-2002 zu den offenen gesharten Klassen die auch ATL benutzt und gehört nicht mehr zur MFC. Die Einbindung kann also ohne Nutzung von Extra-Libraries in jeden WinAPI Code erfolgen. CString ist mittlerweile purer Template Code wie std::string...

Warum sollte es also keinen Platz im WinAPI Forum haben?

CStern

Martin Richter schrieb:

CStern schrieb:

Martin Richter schrieb:

Diese VariantTime auf dei CStern hinweist wird komplett durch COleDateTime gekapselt und ist sehr flexibel und einfach zu nutzen.

Öhm schon ... aber sind wir hier in MFC-Forum? :xmas2:
Wenn ja, muss ich ja flüchten - ich hasse MFC!

Prüfe erst was Du behauptest bevor Du es schreibst

COleDateTime gehört wie CStringT seit VS-2002 zu den offenen gesharten Klassen die auch ATL benutzt und gehört nicht mehr zur MFC. Die Einbindung kann also ohne Nutzung von Extra-Libraries in jeden WinAPI Code erfolgen. CString ist mittlerweile purer Template Code wie std::string...

Warum sollte es also keinen Platz im WinAPI Forum haben?

Meinetwegen. Ich benutze aber lieber die Klasse ... nicht Zuviele schlechte Erfahrungen mit MFC.
Dann ist daneben die Win2003SDK schlecht, weil die kennt diese Klasse ja auch nicht,

also: Wenn ich nicht unbedingt MFC und .NET progge: Woher soll ich das wissen?
Außerdem bin ich kein Freund von verkapseltem! Weil die Umwege das wieder rückgängig zu machen langwieriger sind, als die Kapselung selbst.