HWND != HMENU aber void* == void*



  • Bisher haben bei mir folgende überladene Konstruktoren funktioniert:

    Menu(HWND hwnd);
    Menu(HMENU hmenu);
    

    Aber nun - bin auf Win98 übergewechselt-, nimmt der Compiler das nicht mehr und beklagt sich über doppelte Deklaration (beide Argumente werden jetzt als void* betrachtet, obwohl sonst HWND und HMENU als unterschiedliche Typen behandelt werden).

    Gibt es einen Trick, wie ich das wieder zum laufen bekomme?
    (NB: benutze Borland Compiler)

    Danke,hgf



  • #define STRICT
    #include <windows.h>



  • "STRICT" hilft da leider nicht. Ich hatte STRICT ohnehin schon definiert (und es wegzulassen bringt auch nichts).

    hgf



  • Hmmm... komisch.

    Welches Platform SDK wird denn da reingeladen?

    alle Platform SDK's mit denen ich gearbeitet habe, verwenden

    #ifdef STRICT
    #define DECLARE_HANDLE(name) struct name##__ { int unused; }; typedef struct name##__ *name
    #else
    typedef PVOID HANDLE;
    #define DECLARE_HANDLE(name) typedef HANDLE name
    #endif
    
    DECLARE_HANDLE(HWND)
    

    DECLARE_HANDLE ist definiert in WINNT.h (was won WinDef.h unabhängig von der compiler-platform reingeladen wird)



  • Diese Überladung ist eh nicht so optimal, finde ich.
    Welcher Konstruktor soll denn aufgerufen werden, wenn NULL übergeben wird?

    Probier mal folgendes:
    Definiere STRICT nicht vor dem #include <windows.h>, sondern global in den Compilereinstellungen. Dann ist es nämlich immer und überall definiert.



  • FINAL EDIT:
    Habe jetzt ein einfacheres Programm, in dem die Menu-Klasse ebenfalls vorkommt, compiliert und laufen lassen. Das heisst es scheint dieser Code scheint doch OK zu sein, und der Fehler mit dem #if (wie unten beschrieben) wird irgendwie indirekt ausgelöst.

    Hi CD9000

    Diese Überladung ist eh nicht so optimal, finde ich.
    Welcher Konstruktor soll denn aufgerufen werden, wenn NULL übergeben wird?

    Aufruf explicit mit NULL? Ja, das geht nicht, wird aber auch nicht benötigt und würde letztendlich auch bei einem einfachem Construktor zu einem Fehler führen.
    Als Alternativen sehe ich
    - ein Konstruktor mit Dummy-Variable
    - Abgeleitete Klasse mit eigenem Konstruktornamen
    - Funktion statt Konstruktor benutzen
    Ist alles weniger "kompakt".

    STRICT global in der Compiler Einstellung - ja das habe ich. Trotzdem funktioniert das noch nicht (siehe unten). Habe beides ausprobiert, STRICT als Compiler-Einstellung und STRICT vor dem #include <window.h> in meiner "main.cpp".

    Hi Peterchen,

    ja, mit dem STRICT scheint es zu tun zu haben. In meiner WINNT.H steht genau der Code, den Du mir rauskopiert hast.

    Mir scheint die #ifdef Konstruktion als solche funktioniert nicht.
    Ich habe folgendes probiert:

    #ifdef STRICT //funktioniert nicht und
    #ifndef STRICT //funktioniert auch nicht,
    // ergo es macht keinen Unterschied, ob ich STRICT
    // definiert habe oder nicht, es scheint immer das
    // "nicht-strict" zu lesen

    erst wenn ich #ifdef, #endif und den ganzen #else-Zweig in WINNT.H auskommentiere, so dass nur der if-Zweig (=strict definitions) stehen bleibt, dann geht es.

    Habe keine Ahnung warum das #ifdef nicht funktionieren sollte. Zuerst dachte ich das könnte daran liegen, dass WINDOWS.h mehrfach in meinem Programm includiert ist, ... . Aber dagegen ist es ja geschützt. Und die STRICT Definition ist global und demzufolge unabhängig von der Compilationsreihenfolge.

    Noch Anzumerken: Die Situation ist jetzt (mit der modifizierten WINNT.h) nicht nur STRICT sondern irgendwie superstrict:
    Ich muss jetzt in Funktionen wie SelectObject(..) oder GetObject(..) die verschiedenen Handel's mit HGDIOBJ kasten - in meinem Win95 System war das nicht notwendig, obwohl dort gleichzeitig die überladenen Konstruktoren unterschieden worden sind. Gerade so als ob es 3 verschiedene Levels von Strictness gibt.

    Weiss jetzt noch nicht genau was ich machen werde. Habe gerade meine Maus in Rotwein gebadet - für heute reichts mir erst mal.
    Vielen Dank für Euere Antworten,
    hgf


Anmelden zum Antworten