Datenstruktur für Kalender

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.