WNDCLASS hInstance



  • Hi,

    hatte heute ein merkwürdiges Problem:

    Laut dieser Seite http://msdn.microsoft.com/en-us/library/windows/desktop/ms633576%28v=vs.85%29.aspx muß in das Feld hInstance der Struktur WNDCLASS die InstanceID der Anwendung, welche die Fensterprozedur enthält. Dies scheint nicht ganz richtig zu sein (um nicht zu sagen falsch).

    Eine Anwendung von mir benutzt Dialoge, die wiederum Controls enthalten können, welche über eine eigene Fensterklasse realisiert sind. Es kann vorkommen, daß die Dialoge aber nicht aus der Anwendung geladen werden sondern aus einer DLL. Gebe ich in diesem Fall beim Registrieren meiner Klasse die InstanceID meiner Anwendung an, werden Dialoge, die solche Controls enthalten nicht angezeigt. Die Fensterprozedur meines Dialogs erhält zwar noch Nachrichten, aber dann terminiert CreateDialog mit einem Fehler. Gebe ich aber die InstanceID der DLL an, die nur die Ressourcen enthält keinerlei CODE, funktioniert es, wie es soll.

    Kann da jemand was dazu sagen?

    mfg Martin





  • Jodocus schrieb:

    http://blog.m-ri.de/index.php/2007/12/12/die-unsitte-immer-getmodulehandlenull-fuer-hinstance-in-createwindow-und-registerclass-zu-verwenden/

    Danke. Allerdings geht dieser Artikel nicht darauf ein, daß im WinSDK Help Unfug drinnen steht:

    Identifies the class module. This member must be an instance handle and must not be NULL.

    Windows 3.1 SDK Help

    Identifies the instance that the window procedure of this class is within.

    Win32 Programmer's Reference Help

    Im ersteren Fall ist zu wenig Info im letzteren Fall ist falsche Info. 👎

    Na gut normalerweise ist die Doku von Kleinweich ganz OK, verzeihen wir ihnen also den Schmarrn.

    mfg Martin


  • Mod

    Was ist an der zweiten Antwort bitte falsch?



  • Martin Richter schrieb:

    Was ist an der zweiten Antwort bitte falsch?

    Hi,

    hatte eine EXE mit der Fensterprozedur. Es war auch die EXE, welche die Klasse registriert hat. Das Dialogtemplate war aber in einer DLL, die vorher mit LoadLibrary geladen wurde. In der DLL waren nur die Ressourcen, kein CODE.

    Beim Registrieren durfte ich entgegen der Dokumentation nicht die InstanceID der Anwendung mit der Fensterprozedur angeben sondern mußte das ModuleHandle der Library angeben. Eine andere Alternative, so habe ich das dann auch gelöst, war eben die Klasse global zu definieren.

    mfg Martin


  • Mod

    Und wieso vermischt Du hier einen Aufruf von CreateDialog(Param) mit RegisterWindowClass?

    Der Effekt den Du beschreibst ist eben zu 100% das Resultat aus diesem Satz!
    Identifies the instance that the window procedure of this class is within.

    Liegt ein Dialog-Template in einer DLL dann wird primär auch versucht die Fensterklassen zu diesem Modul aufzulösen. Das wird ihm eben nicht gelingen wenn die Fensterklasse nicht global ist.

    Und das Verhalten ist zu 100% dokumentiert:
    http://msdn.microsoft.com/en-us/library/windows/desktop/ms645434(v=vs.85).aspx

    This function typically fails for one of the following reasons:
    ...
    •the system class was registered by a different module
    ...



  • Martin Richter schrieb:

    Und wieso vermischt Du hier einen Aufruf von CreateDialog(Param) mit RegisterWindowClass?

    Wie meinen? Selbstdefinierte Klassen müssen registriert werden. Dialoge aus einer Ressource werden mit CreateDialog angezeigt. Wo ist da das Problem?

    Martin Richter schrieb:

    Der Effekt den Du beschreibst ist eben zu 100% das Resultat aus diesem Satz!
    Identifies the instance that the window procedure of this class is within.

    Die instance mit der Fensterprozedur ist meine Anwendung. Die instance mit dem Template ist meine DLL. Und da steht eindeutig ohne wenn und aber, man muß die InstanceID der Anwendiung mit der Prozedur angeben.

    Martin Richter schrieb:

    Liegt ein Dialog-Template in einer DLL dann wird primär auch versucht die Fensterklassen zu diesem Modul aufzulösen. Das wird ihm eben nicht gelingen wenn die Fensterklasse nicht global ist.

    Das habe ich nun auch festgestellt.

    Martin Richter schrieb:

    Und das Verhalten ist zu 100% dokumentiert:
    http://msdn.microsoft.com/en-us/library/windows/desktop/ms645434(v=vs.85).aspx

    This function typically fails for one of the following reasons:
    ...
    •the system class was registered by a different module
    ...

    Den Terminus system class habe ich nun nicht mit meiner eigenen Fensterklasse im Zusammenhang gebracht. Ist meiner Meinung nach etwas unglücklich ausgedrückt.

    mfg Martin


Anmelden zum Antworten