Klotzkopp

Dann ist es nach meiner persönlichen Meinung eine Frechheit, andere damit zu belästigen, denn dann erwartest du von den Helfern eine höhere Bereitschaft zur Lösung dieser Aufgabe, als du selbst aufzubringen bereit bist. Du erwartest von anderen Benutzern des Forums, das zu tun, wozu du offenbar selbst zu faul bist. Vielleicht solltest du diese Einstellung mal in Ruhe überdenken. Dieses Forum ist kein Lösungsservice für lästige Hausaufgaben.

Meinst du jetzt mit "Position" eine Art Index, also von Null bis irgendwas, oder die tatsächliche Speicheradresse? Falls ersteres: Das ist Unsinn, denn der nächste Index ist der eigene Index + 1, also redundant. Falls letzteres: Für Speicheradressen verwendet man Zeiger, keine Integer, auch wenn beides letztendlich Zahlen sind. Du kannst dich z.B. nicht darauf verlassen, dass ein int genauso groß ist wie ein struct ADRESSEN*. Außerdem erschwert es die Verwendung der Liste, weil du ständig casts machen musst. Und damit untergräbst du die Sicherheit, die dir die Typstrenge bietet.

Das verstehe ich nicht. Für "Speicheradressen" verwendet man Zeiger, keine ints. Was hast du mit den ints vor?

Es steht doch praktisch schon da: Also: class Time { // ... Time add( int minuten ); // ... };[/CODE]Versuchs doch einfach mal, und zeig uns deine Ergebnisse, dann sagen wir dir, was falsch ist. So ist der Lerneffekt höher

Die File-Streams sind auch Datenströme

next und prev müssen vom Typ struct ADRESSEN* sein, sonst bekommst du damit keine Verkettung hin. Du brauchst ja einen Zeiger auf die nächste/vorherige Struktur. Außerdem solltest du die struct-Deklaration mit einem Semikolon abschließen. Speicher reservieren: struct ADRESSEN* neueAdresse = malloc( sizeof( struct ADRESSEN ) );

Zum Analysieren von Dumpfiles verwendet man Debugger, allerdings sind nicht alle dazu in der Lage. WinDbg z.B. kann das (gibts kostenlos hier). Die Bedienung ist nicht gerade komfortabel, aber die mitgelieferte Hilfe ist sehr ausführlich. Wenn es Minidumps sind (64kByte), muss WinDbg auf die Binaries des abgeschmierten Systems (Kernel, dazugehörige DLLs und Treiber) zugreifen können, um eine ordentliche Analyse machen zu können. Die Debug-Symbole des Systems sind auch immer hilfreich. Der Inhalt des Bluescreens steht sinngemäß auch im Dump, und auszugsweise im Ereignisprotokoll.

Indem du die geforderten Eigenschaften aus dem Aufgabentext in Methoden der Klasse umsetzt. Aus der ersten Aufgabe kannst du zum Beispiel ablesen, dass die Klasse Time einen Konstruktor für zwei Integer Time t0(23, 59) einen Default-Konstruktor Time t1 und eine Methode add braucht. Die add-Methode bekommt einen Integer als Parameter und gibt ein neues Time-Objekt zurück: t1 = t0.and(120); Die Klasse sollte außerdem die Werte für Stunden und Minuten speichern können.

Falsches Forum, drum: --> Verschoben nach: C++: Compiler, IDEs, APIs

Das ist eigentlich immer möglich. Die DLL kann ja einen Fehlercode zurückgeben, wenn der von der EXE übergebene Speicher nicht groß genug ist. Deine DLL und deine EXE verwenden die C-Laufzeitumgebung. Das ist eine Bibliothek, die sich u.a. um den Heap kümmert. Es gibt sie (bei MSVC) in drei Versionen: Single-threaded, Multi-threaded und Multi-threaded DLL. Dazu gibt es jeweils noch eine Debug-Version. Nur die letzte kann man dynamisch linken, d.h. in allen anderen Fällen hast du zwei Laufzeitumgebungen, eine in der EXE und eine in der DLL, und damit auch zwei Heaps. Nur wenn beide die Multi-threaded DLL-Version verwenden, teilen sie sich eine Laufzeitumgebung, und damit auch einen Heap. Die Einstellung, welche Laufzeitbibliothek verwendet werden soll, findest du bei MSVC in den Projekteinstellungen unter C/C++->Code Generation.

Die DLL und die EXE haben jeweils ihren eigenen Heap. Du allokierst auf dem Heap der DLL und gibst auf dem Heap der EXE frei. Du kannst das vermutlich verhindern, indem du für DLL und EXE dieselbe DLL-Version der C-Runtime verwendest. Nicht zuletzt vom Design-Standpunkt gesehen, ist es aber wahrscheinlich besser, wenn die EXE den Speicher selbst holt. --> Verschoben: C++: Compiler, IDEs, APIs

Mit GetActiveView kannst du aus der Frameklasse einen Zeiger auf die aktive View-Instanz bekommen. Den musst du dann nur noch auf den Typ deiner Viewklasse casten.

Leider hilft die Eigenschaft "Komisch" nicht dabei, den Fehler einzugrenzen. Wie lautet die Meldung genau, und wann tritt sie auf? --> Verschoben: C++: Compiler, IDEs, APIs

Ich grüble gerade an der 10. Wirklich nett...

Was ist mit dem Rückgabewert von ReadFile und dem Wert, den Readfile in den vierten Parameter schreibt? Da sollte doch drinstehen, wieviele gültige Bytes im Puffer sind. Das zeitliche Verhalten von ReadFile solltest du über SetCommTimeouts beeinflussen können.

Nein, denn es gibt ja immer nur ein Ahnen-Fenster. Aber du kannst dir mit GetWindow und GW_CHILD das erste Kindfenster des Root-Fensters holen und dessen Handle als Startpunkt für deine Schleife verwenden.

Mit long, short und char schon. Hast du noch andere?

Leider nicht. Es gibt bei den eingebauten Datentypen in C/C++ keine Statusinformation "gefüllt" oder "leer". Man kann Variablen daher auch nicht "leer übergeben". Du kannst deine Funktion so schreiben, dass sie einen bestimmten Wert als "leer" interpretiert (z.B. 0 oder -1), aber das muss der Aufrufer wissen und die Variable auf diesen Wert setzen, wenn er eine "leere" Variable übergeben will. Vielleicht hilft es weiter, wenn du ein wenig Code zeigst, oder genauer beschreibst, wofür du diese Abfrage brauchst.

Es stehen immer Werte in den Variablen. Du kannst bei eingebauten Datentypen in C oder C++ nicht feststellen, ob ihnen schonmal Werte zugewiesen wurden oder nicht.

Was meinst du mit "gefüllt"?

Soweit ich weiß, unterstützt die Klasse CButton keine Transparenz. Aber du kannst mal hier reinschauen: http://www.codeguru.com/buttonctrl/bitmap_text_button.shtml

@Spikex: Da musst du schon mehr Informationen liefern. Geht es um ein Windowsprogramm? Wenn ja, MFC oder oder ein andere Bibliothek oder gar keine? Welche Entwicklungsumgebung? Wenn nicht, was dann? Wie bringst du die Bitmap auf den Button (Code)?

Wie lautet denn der genaue Text der Messagebox (kannst du mit STRG-C kopieren)?

Das kann eigentlich gar nicht passieren. Bist du sicher, dass der Fehler nicht tiefer im Callstack auftritt? Das grüne Dreieck im Debugger von VC++ zeigt dann unter Umständen bereits auf die nächste Zeile.

Mit GW_HWNDFIRST und GW_HWNDNEXT kommst du nur an die Geschwisterfenster von "Me". Da die Fenster in einem Baum angeordnet sind, kommst du so also niemals aus Access heraus. Hol dir mit GetAncestor( Me.hWnd, GA_ROOT ) das Root-Fenster, und versuch es damit mal.