Klotzkopp

Edit -> Advanced -> Format Selection

Du musst den Rückgabewert von GetProcAddress auf den passenden Funktionszeigertyp casten. FARPROC ist da eigentlich nur ein Dummy-Typ.

GetProcAdress "ruft" gar nichts, sondern gibt einen Zeiger auf die Funktion zurück. Mit dem kannst du die Funktion dann aufrufen.

*räusper* std::remove aus <cstdio> passt hier besser.

Nein. Dadurch wird an die bestehende Datei angehängt (app steht für "append" = anhängen). Dann sag einfach nicht, dass du anhängen willst. ios::out | ios::trunc sollte es tun. Dann wird die Datei gleich beim Öffnen geleert.

Wenn die Datei geleert werden soll, warum sagst du dann ios::app?

Startest du irgendwo einen zweiten Thread? Öffnet oder schließt dieser Thread irgendwelche Fenster?

Das ist nicht die gleiche Stelle, an der die erste Assertion fehlschlug. In welcher Datei und Zeile steht der Debugger? Ist das der gesamte Callstack?

Wir brauchen den Callstack zum Zeitpunkt der fehlgeschlagenen Assertion. Wenn also die Assertion-Meldung kommt, klick auf Wiederholen / Retry, dann sollte der Debugger auf dem ASSERT stehen.

In einem C/C++-Programm rufen immer wieder irgendwelche Funktionen andere Funktionen auf. Das beginnt beim Einsprungspunkt des Programms (main, Winmain, etc) und baut sich von dort aus auf. Irgendwann führt das bei deinem Programm zum Aufruf von CWnd::OnCommand. Der Callstack gibt nun wieder, durch welche anderen Funktionen hindurch es zu diesem Aufruf gekommen ist. Ganz oben auf dem Aufrufstapel steht CWnd::OnCommand, darunter steht die Funktion, die CWnd::OnCommand aufgerufen hat, darunter die Funktion, die die darüber aufgerufen hat usw. Über den Callstack lässt sich möglicherweise darauf schließen, was den Fehler verursacht. MSVC kann den Callstack anzeigen, wenn ein "gedebugtes" Programm angehalten ist (durch Breakpoint oder auch Assertion). Eine Assertion ist eine Prüfung von etwas, das eigentlich nicht fehlschlagen darf. Man baut so etwas ein, um Programmierfehler zu finden. Ein Debug-Build bricht mit der bekannten Fehlermeldung ab, wenn eine Assertion fehlschlägt, bei einem Release-Build wird die Prüfung aus dem Programm entfernt. In deinem Fall bedeutet die Zeile ASSERT(nID == 0 || ::IsWindow(hWndCtrl)); dass das Programm prüft, on nId Null ist ODER hWndCtrl ein gültiges Fensterhandle ist. Wenn beides nicht zutrifft, bricht das Programm ab. Es gibt keine dummen Fragen. Wer nicht fragt, ...

Dann musst du eine Klasse von CDialog ableiten, weil du sonst keine Möglichkeit hast, auf diese Steuerelemente zuzugreifen. Das macht aber der Klassenassistent für dich. Starte den Klassenassistent, während die Dialogresource des Wecker-Dialogs angezeigt wird (z.B. über das Kontextmenü), dann sollte er dich fragen, ob er für diese Dialogresource eine Klasse anlegen soll. Von dieser Klasse legst du dann eine Instanz an (an Stelle von CDialog), ohne Dialog-ID als Parameter.

Normalerweise verwendet man nicht CDialog selbst, sondern leitet eine Klasse davon ab. Mit der Basisklasse kann man nicht viel machen, außer statische Texte anzuzeigen und abzufragen, ob der Benutzer OK, Abbrechen oder Schließen betätigt hat. Das sollte kein Problem sein. Meinst du damit, die Anwendung reagiert nicht mehr? Das liegt dann vermutlich daran, dass DoModal nie zurückkommt. Verstehe ich nicht. Was soll das heißen? Nicht ohne weitere Information darüber, wie der Dialog aussieht, und warum du keine Klasse von CDialog abgeleitet hast.

Eigentlich sollte das kein Problem sein. Benutzt das Programm seinen eigenen Pfad? Ändert sich das Verhalten, wenn du über ein Netzlaufwerk auf das Programm zugreifst?

Das ist in CWnd::OnCommand: BOOL CWnd::OnCommand(WPARAM wParam, LPARAM lParam) // return TRUE if command invocation was attempted { UINT nID = LOWORD(wParam); HWND hWndCtrl = (HWND)lParam; int nCode = HIWORD(wParam); // default routing for command messages (through closure table) if (hWndCtrl == NULL) { // zero IDs for normal commands are not allowed if (nID == 0) return FALSE; // make sure command has not become disabled before routing CTestCmdUI state; state.m_nID = nID; OnCmdMsg(nID, CN_UPDATE_COMMAND_UI, &state, NULL); if (!state.m_bEnabled) { TRACE1("Warning: not executing disabled command %d\n", nID); return TRUE; } // menu or accelerator nCode = CN_COMMAND; } else { // control notification [color=red]ASSERT(nID == 0 || ::IsWindow(hWndCtrl));[/color] [/CODE]Es kommt also eine Nachricht von einem Steuerelement, das kein gültiges Fenster (mehr) ist. Nein. Kannst du das mal Debuggen, und den Callstack posten, wenn die Assertion auftritt?

Wo hast du _WIN32_IE definiert, und ist es vielleicht nochmal irgendwo definiert (z.B. in stdafx.h)?

Also bei mir steht in ShellApi.h ab Zeile 645: #if (_WIN32_IE >= 0x0500) #define NIF_STATE 0x00000008 #define NIF_INFO 0x00000010 #endif Bei dir nicht?

<Gebetsmühle> Fehlermeldungen sind für die Diagnose da, nicht zum Wegklicken! Also bitte genau angeben, was da stand. </Gebetsmühle> P.S.: Du kannst den Text einer MessageBox mit Strg-C in die Zwischenablage kopieren.

Bitte die Boardregeln beachten, besonders Punkt 1. Jetzt hast du sie. Thema bis auf weiteres geschlossen. Wenn jemand noch etwas beitragen möchte, PN an mich.

Da haben wir's doch: Wenn das zutrifft, werden die anderen drei "Sonderfälle" gar nicht mehr geprüft, denn die werden von diesem hier vollständig abgedeckt. Entweder schreibst du die drei Sonderfälle davor, oder du änderst diesen in ELSIF v_zehner = 1 AND v_einer > 2 THEN, oder du verschachtelst die IFs.

Dann kommt's wohl darauf an, was für ein BASIC du benutzt...

Wenn du die Windows-typischen Hotkeys meinst, dann setz mal ein & vor den Buchstaben.

Ja, aber nicht zwangsläufig alle. Wenn die IF-Bedingung nicht wahr ist, werden die ELSIF-Bedingungen der Reihe nach geprüft. Sobald eine gefunden wird, die wahr ist, wird der dazu gehörende Block ausgeführt, und danach nichts mehr, weder weitere ELSIFs noch ELSE. Zeig doch einfach mal alle Bedingungen bis zu dem betreffenden ELSIF.

Schon klar, aber wenn die IF-Bedingung wahr ist, wird kein ELSIF ausgeführt. ELSE wird nur ausgeführt, wenn die IF-Bedingung und alle ELSIF-Bedingungen falsch waren.

Wie sieht denn die Bedingung bei "IF" aus? Ein "ELSIF" wird ja vermutlich nur dann ausgeführt, wenn diese nicht wahr war.

for(int i=0;i<feld.length;i++) Die äußere Schleife läuft von vorn nach hinten, d.h. das Feld wird auch von vorn nach hinten sortiert. Insertion Sort bedeutet, dass man das erste Element aus dem unsortierten Bereich an der passenden Stelle im sortierten Bereich einfügt. Das hat zur Folge, dass alle Elemente, die im sortierten Bereich dahinter liegen, um eine Position nach hinten verschoben werden müssen, um dem neu einsortierten Element Platz zu machen: int marker=i; Marker ist die "Einfügemarke", die nach der richtigen Einfügeposition sucht. i ist die Position des ersten Elements im unsortierten Bereich. Hier startet der Marker. int temp=feld; Das ist der einzusortierende Wert. while(marker>0 && feld[marker-1]>temp) Solange der Marker noch nicht am Anfang angekommen ist, und das Element vor dem Marker größer ist als unser einzusortierendes Element... (übrigens, beim ersten Durchlauf der äußeren Schleife wird die innere gar nicht ausgeführt, weil marker == 0) feld[marker]=feld[marker-1]; ... wird das Element vor dem Marker nach hinten verschoben... marker--; ... und der Marker nach vorn gesetzt. Man könnte diese beiden Schritte auch trennen, d.h. man sucht zuerst nach der richtigen Position und verschiebt dann die größeren Elemente eine Position nach hinten. feld[marker]=temp; Nach dem Ende der inneren Schleife sind wir entweder am Anfang des Bereichs angekommen, oder der Marker zeigt auf das Element, das gerade eben noch größer ist als das Einzufügende. Da wir ersteres aber eben noch nach hinten verschoben haben, können wir einfach unseren gespeicherten Wert an der Stelle des Markers einsetzen.