Klotzkopp

Deine DCB-Struktur wird auf dem Stack angelegt, also ist sie zunächst mit zufälligen Werten gefüllt. Da BuildCommDCB nur die Werte in der Struktur setzt, die auch im String stehen, ist die Struktur danach immer noch ungültig. Füll zuerst mit GetCommState die Struktur mit den aktuellen Einstellungen der Schnittstelle, bevor du BuildCommDCB aufrufst, dann sollte das klappen.

signal für STRG-C funktioniert unter Win32 nicht. Man kann SetConsoleCtrlHandler verwenden. Hier steht was dazu: http://www.codeproject.com/win32/console_event_handling.asp

Jede Klasse, die von CWnd abgeleitet ist, erbt diese Variable von CWnd. Wenn du also von CDialog oder CView abgeleitete Klassen hast, dann ist in deren Memberfunktionen diese Variable zugänglich.

Verschoben: --> Datenbanken

Filter.seekg( 0 );

OK, war alles mein Fehler. NotifyChangeEventLog selbst wartet nicht, sondern richtet nur das Event so ein, dass es ausgelöst wird, wenn ein neuer Eintrag ins Event-Log geschrieben wird. D.h. NotifyChangeEventLog wird nur einmal aufgerufen, und danach mit WaitFor... auf das Event gewartet: HANDLE hLog = OpenEventLog( NULL, "System" ); HANDLE hEvent = CreateEvent( NULL, TRUE, FALSE, NULL ); if( NotifyChangeEventLog( hLog, hEvent ) ) { MessageBox( NULL, "NCEL OK", "", MB_OK ); } while( true ) { if( WAIT_OBJECT_0 == WaitForSingleObject( hEvent, INFINITE ) ) { MessageBox( NULL, "Neues Event", "", MB_OK ); } } [/CODE]

So müssen die Pfade nur aussehen, wenn sie in deinem Quellcode stehen. Keinesfalls musst du einen eingelesenen oder aus einer anderen Funktion zurückgegebenen String so bearbeiten. Also bitte kein Replace.

Wie sieht denn der Rückgabewert von GetLastError im else-Block aus?

Andersrum. Wenn NotifyChangeEventLog TRUE zurückgibt, gibt es neue Einträge. Der else-Block wird ausgeführt, wenn beim Ausführen von NotifyChangeEventLog ein Fehler auftritt. Rufst du EventTest::Execute eventuell nur einmal auf? Dann ist das klar.

Für managed C++ verwendest du wohl besser System.IO.File.Move.

Der zweite Parameter muss FALSE sein, weil NotifyChangeEventLog ein manuell zurückzusetzendes Event erwartet. Ein Auto-Reset-Event, wie das, das du erzeugst, funkioniert möglicherweise nicht richtig. Du musst den Rückgabewert von NotifyChangeEventLog verarbeiten. Was du tust, ist NotifyChangeEventLog aufzurufen, den Rückgabewert zu verwerfen, und danach den Funktionszeiger auf NotifyChangeEventLog mit NULL zu vergleichen, was niemals wahr sein wird. Das hier sollte funktionieren: if( NotifyChangeEventLog( hLog, hEvent ) ) { // Neue Events } else { // Fehler }[/CODE] Ich weiß nicht genau, was du mit "deaktiviert" meinst, aber ein Programm, dessen Fenster im Hintergrund oder minimiert ist, läuft normal weiter.

Kennst du denn deinen "Datenbankordner"? Wenn ja, dann setz doch einfach diesen Pfad vor "\temp\Dateiname". Zum Kopieren gibt es CopyFile.

Das ist veraltet. Verwende #include <iostream> Wenn du nicht vor jedes cin und cout std:: schreiben willst, auch noch using namespace std; Die beiden brauchst du gar nicht. Das muss int main() heißen. Diese Zeilen bewirken nichts, die kannst du also auch weglassen. Das ist nicht das, was du willst. Hier wird das Ergebnis des Vergleichs (ausw == Zeichen) mit einem anderen Zeichen logisch oder-verknüpft. Das Ergebnis ist, weil das Zeichen nicht das Nullzeichen ist, immer wahr. Was du meinst, ist: else if (ausw=='m' || ausw=='M') usw.

Du musst den Rückgabewert von OpenEventLog speichern, denn das ist das ist das erste Handle, das du bei NotifyChangeEventLog angeben musst. Das andere ist ein Event, das du selbst mit CreateEvent erzeugen musst: HANDLE hLog = OpenEventLog( NULL, "System" ); HANDLE hEvent = CreateEvent( NULL, TRUE, FALSE, NULL ); NotifyChangeEventLog( hLog, hEvent ); Beachte, dass der Aufruf von NotifyChangeEventLog blockt, d.h. wenn nicht dein ganzes Programm an dieser Stelle stehenbleiben soll (sprich: es soll noch etwas anderes tun), dann musst du diesen Code in einem neuen Thread ausführen.

Es wird aber keine Windows-Botschaft erzeugt, nur weil irgend jemand OpenEventLog aufruft. Ich kenne TEvent nicht, aber ich würde mich sehr wundern, wenn es in der Lage wäre, einen Hook für eine beliebige API-Funktion zu erstellen. Da wird dir nichts anderes übrig bleiben, als in regelmäßigen Abständen das Eventlog zu öffnen und nachzusehen.

Mir ist nicht ganz klar, was du da machen willst. 1. Du ereugst ein neue Instanz von TEvent, legst die Adresse in deinem Zeiger ab, und überschreibst dann den Zeiger durch eine erneute Zuweisung. Damit ist die Instanz nicht mehr zugänglich -> Speicherleck. 2. OpenEventLog (ohne Klammern) ist ein Funktionszeiger. Ich kann mir nicht vorstellen, welchen Sinn es machen könnte, diesen in einem TEvent* zu speichern. Der Compiler kann das nicht, daher die Fehlermeldungen. Wenn du das trotzdem machen willst (wie gesagt, für mich macht das keinen Sinn), dann musst du den Zeiger mit reinterpret_cast oder einem C-Style-Cast umwandeln. Damit sagst du dem Compiler: "Vertrau mir, ich weiß, was ich mache".

Mein Lösungsansatz leitet die Anzahl der befallenen Pferde direkt aus der Nacht ab, in der sie die Koppel verlassen haben. Wären es nur zwei gewesen, hätten sie die Koppel schon in der ersten Nacht verlassen können, usw.

Also ich denke mir das so: Ich meine ja, dass es 6 befallene Pferde sind. Das heißt also, diese 6 Pferde sehen 5 Kreuze, alle anderen sehen 6. Die Pferde, die 5 Kreuze sehen, denken sich: "Ich sehe 5 Kreuze, also sind entweder 5 oder 6 Pferde befallen. Angenommen, es wären 5, dann würden diese 5 nur vier Kreuze sehen. Was würden diese 5 denken?" "Ich sehe 4 Kreuze, also sind entweder 4 oder 5 Pferde befallen. Angenommen, es wären 4, dann würden diese 4 nur 3 Kreuze sehen. Was würden diese 4 denken?" "Ich sehe 3 Kreuze, also sind entweder 3 oder 4 Pferde befallen. Angenommen, es wären 3, dann würden diese 3 nur 2 Kreuze sehen. Was würden diese 3 denken?" "Ich sehe 2 Kreuze, also sind entweder 2 oder 3 Pferde befallen. Angenommen, es wären 2, dann würden diese 2 nur 1 Kreuz sehen. Was würden diese 2 denken?" "Hm, ich sehe nur ein Kreuz. Da es mindestens zwei befallene Pferde sind, bin ich auch befallen. Mift[tm]!". Diese beiden würden in der ersten Nacht die Koppel verlassen. Wenn dies nicht passiert, würden alle Pferde, die zwei Kreuze sehen, am 2. Tag wissen, dass es 3 befallene Pferde sind, und in der 2. Nacht die Koppel verlassen. Wenn dies nicht passiert, würden alle Pferde, die 3 Kreuze sehen, am 3. Tag wissen, dass es 4 befallene Pferde sind, und in der 3. Nacht die Koppel verlassen. Wenn dies nicht passiert, würden alle Pferde, die 4 Kreuze sehen, am 4. Tag wissen, dass es 5 befallene Pferde sind, und in der 4. Nacht die Koppel verlassen. Wenn dies nicht passiert, würden alle Pferde, die 5 Kreuze sehen, am 5. Tag wissen, dass es 6 befallene Pferde sind, und in der 5. Nacht die Koppel verlassen. Und das ist passiert. Also waren es 6 befallene Pferde. Das erfordert aber, dass die Pferde alle ziemlich schlau sind.

Ich komme auf 6. Das müssen aber ziemlich schlaue Pferde gewesen sein.

Indem du Zeile 22 in Unit1.cpp auskommentierst. Im Ernst, wie sollen wir dir helfen, den Fehler zu beheben, wenn du nicht einmal die fehlerhafte Zeile zeigst? Ich kann nur soviel sagen, das TEvent keinen passenden Konstruktor für die Typen der Parameter, die du angegeben hast (int, bool, bool und void * (__stdcall *)(const char *,const char *)), anbietet.

Ein quadratischer Deckel kann in den passenden Schacht hineinfallen, ein runder nicht.

Richtig. Der zweite Parameter des ON_NOTIFY-Makros gibt die Kind-Id des sendenden Steuerelements an. Hier setzt der Klassenassistent fälschlicherweise die ID des List Control selbst ein. Die Nachricht stammt aber vom Header Control, das wiederum ein Kind des List Control ist. Da das Header Control immer die Kind-ID Null hat, funktioniert die Änderung. Dieser "Workaround" hat aber den Nachteil, das bei mehreren List Controls alle Headernachrichten in derselben Funktion aufschlagen, weil ja alle Header Controls dieselbe ID haben. Um das wieder aufzulösen, kann man das Handle des Elternfensters des Header Controls ermitteln und mit den Handles der List Controls vergleichen: void CMeinDlg::OnHdnItemclickList1(NMHDR *pNMHDR, LRESULT *pResult) { LPNMHEADER phdr = reinterpret_cast<LPNMHEADER>(pNMHDR); HWND hListCtrl = ::GetParent( phdr->hdr.hwndFrom ); if( hListCtrl == m_list1.GetSafeHwnd() ) { // List Control 1 } else if( hListCtrl == m_list2.GetSafeHwnd() ) { // List Control 2 } // ... *pResult = 0; }[/CODE]

Was mir bisher aufgefallen ist: - Integrierte Unterstützung des Compact Framework - Visual J# - verbesserter (native) C++-Compiler - erweiterte Automatisierungsschnittstelle Details gibt's hier: http://msdn.microsoft.com/library/en-us/vsintro7/html/vxoriWhatsNewInVisualStudioNET2003.asp

Der Klassenassistent von VC6 generiert bei Headerbenachrichtigungen eines List Control falsche MessageMap-Einträge. Wahrscheinlich steht in der cpp-Datei deines Dialogs in etwa das: ... ON_NOTIFY(HDN_BEGINDRAG, IDC_LIST1, OnHdnBegindragList1) ON_NOTIFY(HDN_ENDDRAG, IDC_LIST1, OnHdnEnddragList1) ... Wenn du IDC_LIST1 (oder was auch immer die Resource-ID deines List Controls ist) durch 0 ersetzt, sollte es funktionieren. VC7 hat diesen Bug übrigens nicht mehr

Nein, denn 10 hoch (log x) ist x, nicht (log x) hoch 10. Und 10 hoch 1 ist 10.