Klotzkopp

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?

In pop führst du grundsätzlich immer free(head) aus. Und ich rate dir nochmals, dir diese fiesen #define-Konstrukte abzugewöhnen. In C++ braucht man die nun wirklich nicht mehr.

Dann darfst du dafür eben keine globalen Variablen benutzen, sondern musst dir eine passende Datenstruktur ausdenken. Ein assoziativer Container mit dem Fensterhandle als Schlüssel würde mir da zuerst einfallen

Das ist Absicht. "Behaviour by design", wie man so schön sagt. Wie gesagt, das ist Absicht. Wenn du die Nummer bei jedem Aufruf von LoadLibrary hochzählen willst, warum machst du das nicht in DllMain? Nein.

Den Hotkey kann man doch einstellen. Der Defaultwert liegt, wenn ich mich richtig erinnere, auf Alt Gr.

Wie gesagt, für sich allein nicht. Das könntest du. Aber erstens ist ein Zeiger auf einem 32Bit-System 4 Byte groß, und ein int meist auch. Zweitens, und das ist wichtiger, hättest du eine ganz andere Funktion. So, wie sie jetzt ist, hast du keine Möglichkeit, durch Zuweisungen an int_func_test die Variable int_test zu ändern. Mit einem Zeiger wäre das möglich. Daher sind die Fälle gar nicht vergleichbar. Felder (Arrays) werden bei Funktionsaufrufen sowieso nicht kopiert. Allgemein kann es sich lohnen, wenn man beim Funktionsaufruf das Kopieren der Parameter verhindert. Das macht man aber in C++ üblicherweise nicht mit Zeigern, sondern mit konstanten Referenzen. Das Terminierungszeichen ist das Nullzeichen ('\0'). Bei Literalen wird es automisch hinzugefügt. Bei Stringfunktionen steht es in der Dokumentation. Eine Begrenzung gibt es prinzipiell nur durch den verfügbaren (virtuellen) Speicher.

Der Kontext muss sich dann aus der Dokumentation dieser Schnittstelle ergeben. Dort muss z.B. stehen, ob du diesen Zeiger auf selbst allokierten Speicher setzen musst und wie dieser Speicher organisiert sein muss. Für einen Zeiger wird auch Speicher reserviert. Ein Zeiger allein bringt dir aber nichts. Damit du mit einem Zeiger etwas anfangen kannst, muss er auf eine existierende Variable zeigen. Mir ist nicht klar, wovon du da redest. Was für eine "Unterfunktion"?

Die MFC sind schon sehr alt, die ersten Versionen sind älter als der C++-Standard. Die MFC benutzen auch nirgendwo Referenzen (AFAIK). Daher ist die einzige Möglichkeit, wie eine MFC-Funktion einen ihrer Parameter ändern kann, die, statt dessen einen Zeiger zu übergeben. Dazu kommt, dass die MFC immer noch jede Menge mit C-Strings und roher Speicherpuffern macht. Da geht es nicht ohne Zeiger. Auf keinen Fall. Zeiger sollte man nur dort einsetzen, wo sie auch geeignet sind. Wenn du keine Zeiger brauchst, kannst du dich glücklich schätzen. Das ist die (ältere) K&R-Schreibweise, aus Kompatibilitätsgründen im ANSI-C-Standard enthalten. Nein. Prinzipiell verbrauchen Zeiger zusätzlich Speicher.

Als Literal: mit einem L davor: L"c:\\winnt\\system32" Ansonsten WCHAR statt char. CStringW funktioniert jedenfalls in VC7.1.

Du musst in der BROWSEINFO-Struktor dem Member lpfn eine Callbackfunktion zuweisen. In dieser kannst du dann auf die Nachricht BFFM_INITIALIZED reagieren und dem Dialog eine BFFM_SETSELECTION-Nachricht schicken. Den Pfad kannst du z.B. über den lParam-Member der BROWSEINFO-Struktur in die Callbackfunktion bekommen, wie in diesem Beispiel: int CALLBACK BrowseForFolderCallback(HWND hWnd, UINT uMsg, LPARAM lParam, LPARAM pData) { if(BFFM_INITIALIZED == uMsg) { SendMessage(hWnd, BFFM_SETSELECTION, TRUE, pData); } return 0; }[/code] Beachte, dass pData hier auf einen Unicode-String zeigen muss. http://msdn.microsoft.com/library/en-us/shellcc/platform/shell/reference/callbackfunctions/browsecallbackproc.asp

Wenn OnRunabcwrap eine MFC-Nachrichtenbehandlungsfunktion ist (das "On" am Anfang legt das nahe), dann darfst du da auf keinen Fall irgendwelche Parameter hinzufügen oder entfernen. Diese Funktionen werden vom MFC-Framework über einen gecasteten Funktionszeiger aufgerufen. Wenn da die Signatur nicht passt, zerlegt es dir den Stack. Das kann zu den beschriebenen Problemen führen. Nach dem Aufruf wird dann eine CString-Instanz vom Stack entfernt, die nie darauf angelegt wurde.

Du kannst eine Funktion, die zwei Parameter hat, nicht ohne Parameter aufrufen, Es sei denn, beide Parameter hätten Defaultwerte oder die Funktion hat eine variable Parameterliste (...). Wie sieht denn die Deklaration von abc aus? WICHTIGER NACHTRAG (sorry für's Schreien) Kann es sein, dass die diese Funktion (OnRunabcsplit) eine Nachrichtenbehandlungsfunktion für einen Button oder etwas in der Art ist? Und hast du die Parameter nachträglich hinzugefügt?

Da wäre ich sehr vorsichtig. Was du gemacht hast, ist offenbar eine Symptombehandlung. Der Fehler ist vermutlich noch da, aber du hast dafür gesorgt, dass er sich vorerst nicht mehr auswirkt. Womöglich überschreibst du jetzt eine andere Variable, bei der das nicht gleich auffällt. Vielleicht wirkt es sich erst dann aus, wenn du von Debug auf Release umstellst. Das ist gefährlich. Je länger du das tatsächliche Beheben dieses Fehlers vor dir herschiebst, desto teurer wird es.

Wozu brauchst du da einen ASCII-Code? Gibt es dafür nicht "IS NULL" in SQL?

strcore.cpp ist eine Quellcodedatei der MFC: void CString::Release() { if (GetData() != _afxDataNil) { [B]ASSERT(GetData()->nRefs != 0);[/B] if (InterlockedDecrement(&GetData()->nRefs) <= 0) FreeData(GetData()); Init(); } } [/code] [code]void PASCAL CString::Release(CStringData* pData) { if (pData != _afxDataNil) { [B]ASSERT(pData->nRefs != 0);[/B] if (InterlockedDecrement(&pData->nRefs) <= 0) FreeData(pData); } } Zu diesem Zeitpunkt ist dieser CString intern schon "kaputt". Der Fehler passiert also früher.

Siehe dazu meine Signatur Nicht direkt. Es gibt halt diverse Stolpersteine, wie z.B. das sich die printf/scanf-Funktionen nicht mit den C++-Objekten vertragen. Außerdem sieht es sehr seltsam aus. Ok. Der dicke Fehler im Code is wie gesagt der, dass du std::string als Parameter für fprintf benutzt, das kann nicht gutgehen. Du könntest std::string::c_str benutzen, um einen char const * zu bekommen, mit dem kommt fprintf zurecht. Ich würde aber vorschlagen, dass du das Programm erst mal komplett entweder auf die C-Dateifunktionen oder die C++-Streams umstellst. Möglicherweise läuft's dann ja schon Ohne die würde es sich gar nicht kompilieren lassen. Allerdings solltest du die Dateinamen in spitze Klammern statt in Anführungszeichen setzen.

- Warum mischst du die C-Dateifunktionen (fopen, fprintf) mit den C++-Streams? - Warum ist datei1 static? - Wie soll denn die Ausgabedatei aussehen? Bei mir stürzt den Programm übrigens noch bei der Verarbeitung der ersten Zeile ab. Du benutzt std::string als Parameter für fprintf, das erzeugt undefiniertes Verhalten.

Nein. Löse dich von dieser Vorstellung. Du versteifst dich darauf, dass der Fehler da passiert, wo er sich bemerkbar macht. Das muss aber nicht so sein. CConvertOP ist eine Klasse, keine Funktion. Welchen Wert hat eigentlich der "schlechte" Zeiger?

Hat CABCboxDlg noch andere Member? Gibt es im Code überhaupt irgendwelche Arrays, auf die über den Index zugegriffen wird?

Das ist die Deklaration der Membervariablen. Wo legst du die Instanz von CCOnvertOP an? Wenn du möchtest (und es keine Probleme mit der Geheimhaltung gibt), kannst du mir auch das Projekt schicken und ich schau mal rein.

Heapfehler-Thread abgelöst: http://forum.fachinformatiker.de/showthread.php?p=766596

Unwahrscheinlich Das sind schon mal drei:

Der Fehler liegt nicht an diesem CString selbst, sondern vermutlich in der Benutzung der Variablen, die im Speicher davor oder dahinter stehen. Hat die Klasse, zu der m_sInputConvert gehört, noch andere Member? Wo erzeugst du die Instanz dieser Klasse?

CString kann theoretisch überlaufen, aber bevor das passiert, würde es wohl irgenwo anders knallen. Wahrscheinlicher ist, dass du irgendwo über eine Arraygrenze hinausschreibst und dabei den internen Zeiger des CString änderst.