Probleme mit Konstanten aus der Resource.h
-
Ich habe in einem Programm eine Dialogklasse, die mehrere Editfelder und Buttons beinhaltet. Diese habe ich jetzt in eine DLL ausgelagert. Jetzt bringt mir der Kompiler für jedes dieser Felder eine Fehlermeldung (error C2065: 'IDC_EDIT_BENUTZER': nichtdeklarierter Bezeichner). Ich hab in der entsprechenden cpp-Datei die Resource.h includiert. In dieser stehen auch die IDs richtig drin. Witzigerweise zeigt er auch, wenn man mit dem Mauszeiger auf den Eintrag geht #define IDC_EDIT_BENUTZER 1031. Auch unter Resourcensymbole werden die IDs im Resourceneditor korrekt und als verwendet angezeigt. Was mach ich da falsch? Bereinigt hab ich schon mehrfach...
-
Du hast vermutlich mehrere resource.h Dateien...
-
Martin Richter schrieb:
Du hast vermutlich mehrere resource.h Dateien...
Nein, es gibt nur die eine, die im dll-Projekt existiert. Ändere ich da einen Zahlenwert, so ändert sich auch die Anzeige im Tooltip, wenn man mit der Maus auf die entsprechende IDC_xxx-Konstante zeigt. Trotzdem findet er beim Kompilieren die Definition nicht.
-
Martin Richter schrieb:
Du hast vermutlich mehrere resource.h Dateien...
Hmmm, ich hab jetzt mal mit einen Rechtsklick die Datei Resource.h hinter dem #include "Resource." geöffnet. Dabei wird die resource.h aus dem Platform SDK gezogen. Gibts dafür eine Erklärung? Gebe ich nämlich explizit den Dateipfad an, dann geht auch das kompilieren ohne Probleme. Wieso ist das so?
-
Ich kenne keine resource.h aus dem Platform SDK!
Zudem würde immer eine resource.h in dem selben Verzeichnis wie das Modul zuerst gezogen.
Deine Pfade stimmen nicht...räum auf und gut ists.
-
Martin Richter schrieb:
Ich kenne keine resource.h aus dem Platform SDK!
Also die Datei liegt im Verzeichnis C:\Programme\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include und die zieht er als erstes irgendwie.
Martin Richter schrieb:
Zudem würde immer eine resource.h in dem selben Verzeichnis wie das Modul zuerst gezogen.
Deine Pfade stimmen nicht...räum auf und gut ists.Soweit ist mir das auch klar, nur er machst irgendwie nicht. Die Datei existiert im Projektpfad und ist auch im Projekt eingebunden. Wenn ich den Pfad explizit angebe gehts auch. Was soll ich denn da jetzt aufräumen?
-
Deine Resource-h liegt sicher in dem Verzeichnis in dem Deine C/CPP Datei liegt die den include macht?
Sicher
Ganz sicherDas Projektverzeichnis ist vollkommen uninteressant für einen #include, wenn Du die Dateien in Unterverzeichnisse legst.
-
Martin Richter schrieb:
Deine Resource-h liegt sicher in dem Verzeichnis in dem Deine C/CPP Datei liegt die den include macht?
Sicher
Ganz sicherDas Projektverzeichnis ist vollkommen uninteressant für einen #include, wenn Du die Dateien in Unterverzeichnisse legst.
Absolut ganz sicher. Die Dateien liegen alle im gleichen Verzeichnis (so wie immer). Was ich eben nicht verstehe ist, dass der Tooltip die richjtige Belegung der Konstanten darstellt, der Kompiler die Definition aber nicht findet. Wie kann man sich das erklären?
-
AndyDD schrieb:
Was ich eben nicht verstehe ist, dass der Tooltip die richjtige Belegung der Konstanten darstellt, der Kompiler die Definition aber nicht findet. Wie kann man sich das erklären?
Beide parsen Deine Dateien anders, oder verwenden andere Suchpfade...
Auf die IDE kannst Du Dich in diesem Fall nicht verlassen!Hast Du evtl. in den Include Pfaden was anderes eingetragen?
-
Man beachte auch, dass ein
#include "..."etwas anderes ist als ein
#include <...>Beim zweiten wird im Projektverzeichnis *nicht* gesucht...
-
Martin Richter schrieb:
AndyDD schrieb:
Was ich eben nicht verstehe ist, dass der Tooltip die richjtige Belegung der Konstanten darstellt, der Kompiler die Definition aber nicht findet. Wie kann man sich das erklären?
Beide parsen Deine Dateien anders, oder verwenden andere Suchpfade...
Auf die IDE kannst Du Dich in diesem Fall nicht verlassen!Hast Du evtl. in den Include Pfaden was anderes eingetragen?
Bei den Includepfaden verweise ich zusätzlich auf ein Verzeichnis, in dem ich Dateien allgemein zu verwendender, von mir erstellter Klassen aufbewahre. Dies sind aber in der Regel Klassen, die keine Resourcen binden (z.B. Wrapperklassen für Berechnungen von Koordinatentransformationen). Wo sieht man denn, wie die IDE und der Kompiler in welcher Reihenfolge sucht?
-
Jochen Kalmbach schrieb:
Man beachte auch, dass ein
#include "..."etwas anderes ist als ein
#include <...>Beim zweiten wird im Projektverzeichnis *nicht* gesucht...
Es ist durch #include "Resource.h" realisiert. Auch ein #include ".\Resource.h" hilft da nicht...
-
Ich weiß zwar nicht warum, aber es geht. Ich hatte in der Erweiterungs-DLL eine weitere DLL eingebunden. Hab dies jetzt rückgängig gemacht und den Code direkt implementiert. Jetzt lässt es sich zwar kompilieren, beim Aufruf des Dialogs aus der DLL wird dieser allerdings nicht angezeigt. Was kann dafür die Ursache sein?
Irgendwas scheint ganz schön vermackt zu sein an meinem Projekt...
-
AFX_MANAGE_STATE drin?
-
Martin Richter schrieb:
AFX_MANAGE_STATE drin?
Ich verwende eine MFC-Erweiterungs-Dll, da ist das glaub ich nicht angebracht...
-
Stimmt. Bei einer Erweiterungs DLL sollte in der Liste der DLLs gesucht werden. Gibt es evtl. ein Duplikat der ID zur Anwednung?
-
Martin Richter schrieb:
Stimmt. Bei einer Erweiterungs DLL sollte in der Liste der DLLs gesucht werden. Gibt es evtl. ein Duplikat der ID zur Anwednung?
Ich hab jetzt ein neues Projekt angelegt und diesem einen anderen Namen gegeben. Dann hab ich den Quellcode in die entsprechenden Klassen reinkopiert und jetzt ist das Problem weg. Hab dafür keine Erklärung.
-
Ich hatte Dir nur raten können in den MFC Code zu debuggen und zu sehen wo er denn wirklich sucht nach dem Template...
-
Martin Richter schrieb:
Ich hatte Dir nur raten können in den MFC Code zu debuggen und zu sehen wo er denn wirklich sucht nach dem Template...
Wie debuggt man eine dll stand alone? Das habe ich noch nie gemacht...
-
Nicht stand alone. Das geht nicht. Eine DLL benötigt immer einen Prozess.
Entweder attached Du Dich an den Prozess, der die DLL laden wird und debuggest dort (der muss ja keine Debug-Infos haben).
Oder Du gibst den Prozess direkt bei den Debug Optionen an im DLL Projekt.
