Klotzkopp

"Laufen" würde ich das nicht nennen. 9 und 15 sind jedenfalls keine Primzahlen. Dein Programm gibt alle ungeraden Zahlen aus. Das liegt daran, dass du eigentlich nur die Teilbarkeit durch zwei prüfst. Danach beendest du deine Teilersuchschleife in jedem Fall mit einer return-Anweisung.

Danke für die Links, die sind sehr interessant. Ich halte deine Einwände für grundsätzlich richtig. Allerdings darf man hier nicht außer acht lassen, dass es um MFC und vor allem um Anfänger geht. Benutzerdefinierte Nachricht bedeutet, dass man selbst Hand an die MFC-MessageMap legen muss. Allein dabei kann viel schiefgehen. Oft genug habe ich schon gesehen, dass dabei die falsche Map benutzt wurde. Praktisch alles, was man dabei falsch machen kann, führt zu logischen Fehlern, die man (über ein Forum) nur schwer finden kann. Die Vorgehensweisen, die auf den von dir verlinkten Seiten vorgeschlagen werden, haben sogar noch mehr mögliche Fehlerquellen, wenn sie denn überhaupt auf die MFC anwendbar sind: Ich denke, so etwas kann man Anfängern - und mit solchen haben wir es hier im Forum nun mal meistens zu tun - nicht zumuten.

Das sehe ich nicht so. Ich stimme dir zu, dass das kein "Dialog" im engeren Sinne mehr ist. Andererseits hat ein modaler Dialog den großen Vorteil, dass er, so lange er läuft, jegliche Interaktion mit dem Elternfenster verhindert. Damit hat man klare Schnittstellen, gerade für einen Vorgang, den der Benutzer nicht beeinflussen kann, sobald er gestartet ist. Bei einem normalen Fenster müsste man mehr oder weniger umständlich dafür sorgen, dass der Benutzer nicht dazwischenfunkt.

Wenn du ODBC benutzt, brauchst du die Automatisierungsschnittstelle nicht. Startpunkt ist immer _Application, wie auch in dem Beispielcode im verlinkten Thread.

Sind die einzelnen Buttons Kindfenster der Toolbar? Dann könntest du die einfach durchenumerieren.

Nicht so, dass es ein Mensch bemerken würde. CWnd::SetTimer, CWnd::KillTimer. Das sind aber schon Dinge, die nicht so ohne weiteres ohne eine laufende Nachrichtenschleife funktionieren. Du solltest so etwas definitiv nicht in OnPaint machen. Das liegt daran, dass Assertions im Release-Modus vom Präprozessor entfernt werden. Der Fehler ist immer noch da, du wirst nur nicht mehr darauf hingewiesen. Was heißt "schmiert ab"? Startest du im Debugger? Wie sieht der Callstack aus?

In dem verlinkten Thread stand auch nichts vom Projektmenü. Da stand: ClassWizard->Automation-Add Class->From a type library Auf Deutsch etwa: Klassenassistent -> Automatisierung-Klasse hinzufügen -> Aus einer Typbibliothek. Eher zum Weinen Stellst du das nur zur Unterhalten hier rein, oder möchtest du Kommentare dazu?

Das soll vermutlich "Laufzeitfehler" heißen... Genial!

Das steht in der MSDN Library, in der Beschreibung der OSVERSIONINFO-Struktur. Es ist übrigens nicht sehr höflich, seine Frage wieder zu löschen, wenn man selbst eine Antwort gefunden hat. Damit bringt man den nächsten, der das Problem hat, um die Möglichkeit einer schnellen Lösung

Das Problem liegt vermutlich darin, dass du das ganze in OnPaint machst. Üblicherweise benutzt man für so etwas einen Timer mit kurzem Intervall, der in OnInitDialog gestartet wird, und sofort, nachdem er zum ersten Mal ausgelöst hat, wieder zerstört wird. Du musst dir allerdings im Klaren sein, dass du das Fenster hier nur begrenzt beeinflussen kannst, weil die Nachrichtenschleife steht, solange deine Funktion läuft. Das Problem ließe sich nur mit einem weiteren Thread lösen.

Und passiert in OnEditCell etwas, was du selbst machen könntest? Wenn gar nichts hilft: Ableiten und eine public-Methode schreiben, die OnEditCell aufruft (blutiger Hack ).

Könnte man. Das VBA-Programm liest allerdings nicht aus, sondern benutzt nur die interne Speicherfunktion von Excel. Wenn du die Daten anders aufbereiten oder an ein anderes Programm weitergeben willst, hilft dir das nicht. Du kannst ja mal hier reinschauen (nicht wundern, wenn da eine Antwort ohne Frage steht ) http://forum.fachinformatiker.de/showthread.php?t=20841 Das könnte auch noch helfen: http://forum.fachinformatiker.de/showthread.php?t=70912

Ich wiederhole mich auch gern nochmal: Soll das eine Übungsaufgabe sein? Falls ja, gibt es noch weitere Vorgaben? Darfst du die Automatisierungsschnittstelle benutzen? Der Ansatz hängt von der Antwort auf diese Fragen ab.

Ich meine, du sollst im Quellcode des Steuerelements nachsehen, was da bei einem Doppelklick passiert.

Soll das eine Übungsaufgabe sein? Excel kann so etwas nämlich auch ganz gut selbst. Falls ja, gibt es noch weitere Vorgaben? Darfst du die Automatisierungsschnittstelle benutzen?

Ich hab selbst keine. Aber ich denke, meine Frau kommt mit ihrer ganz gut klar.

ShellExecute mit "open" sollte auch mit Borland funktionieren.

Ich kenne das Steuerelement nicht. Aber warum schaust du nicht im Quellcode nach, was bei einem Doppelklick passiert? Möglichweise kannst du das gleiche machen.

Nein. Wenn du eine (generierte) Headerdatei hast, musst du die mit #include einbinden. Eine Typbibliothek (.tlb) bindest du mit #import ein. #include <windows.h> #include <atlbase.h> #import "comserver.tlb" // ODER #include "comserver.h" int main() { CoInitialize(0); { CComPtr<Icomserver> p; HRESULT hr = p.CoCreateInstance(__uuidof(comserver)); if(SUCCEEDED(hr)) { p->Methoder(1, 42.0); } } } [/code]

Eine Möglichkeit ist, mit der #import-Direktive die Typbibliothek zu importieren und dann mit CoCreateInstance eine Instanz zu erzeugen. Die ATL bietet dazu ein paar schöne Hilfsklassen, wie z.B. Smartpointer.

Das liegt daran, dass std::map::iterator auf ein std::pair verweist. Mit it->first kommst du an den Schlüssel (long), mit it->second an den Wert (CKanal*).

Passt irgendwie nicht zusammen...

Mal ein Beispiel: int a; a = 5; a = 2;[/code] Wo ist die 5? Richtig, die ist weg, überschrieben durch die 2. Das gleiche machst du da. Du überschreibst den Zeiger auf den Speicherbereich, den du mit new geholt hast, mit der Adresse von data. Gleiches Verhalten wie vorher, aber jetzt noch ein zusätzliches Speicherleck. Stichwort: strcpy. Übrigens solltest du new und malloc nicht mischen.

Ich habe nicht gesagt, dass du die Makros ersatzlos streichen kannst. Aber auch das lässt sich besser lösen. Aber zum eigentlichen Problem: sNode::Elem ist ein Element, und das ist nur ein char*. Du reservierst aber nirgendwo Speicher für einen Text, du weist immer nur die Adresse des Puffers zu, den du zum Einlesen benutzt. Daher zeigen alle Einträge auf denselben Speicherbereich, und haben somit auch denselben Text.

Eigentlich nicht. Bis auf die merkwürdigen CASE und DEFAULT-Makros lässt sich das alles auch viel besser lösen. Du kannst übrigens ein typedef nicht mit #ifdef prüfen; da lassen dich die Makros schon im Stich. Jedenfalls dekrementierst du in pop(Element_ID) die ID des letzten Eintrags nicht. Wie wäre es denn, wenn du mal etwas genauer beschreibst, wie sich der Fehler reproduzieren lässt und wie er sich genau äußert?