hInstance in CreateWindow

Das kann man aber übrigens auch, wie Jeder wissen sollte, im Petzold auf Seite 1296 im 3.Paragraph nachlesen!!! Bitte zukünftig erstmal im Petzold nachschauen, bevor man so eine Frage stellt. Stell dir den Petzold wie eine Neuauflage der Bibel vor, da steht einfach alles drin!

Also in meinem Petzold (5. Auflage) steht auf Seite 1296 'ne Menge Wissenswertes über Sockets, aber nichts über CreateWindow ...
Trotzdem Danke.

Okay, eigentlich wollte ich wissen, ob ich an der Stelle auch den von GetWindowLong (hDlg, GWL_HINSTANCE) gelieferten Wert einsetzen kann; dazu hab ich festgestellt, daß der mit hInstance aus WinMain identisch ist - ich gebe hInstance ja beim Dialogerstellen als Parameter mit an.

CStern

Belli schrieb:

Okay, eigentlich wollte ich wissen, ob ich an der Stelle auch den von GetWindowLong (hDlg, GWL_HINSTANCE) gelieferten Wert einsetzen kann; dazu hab ich festgestellt, daß der mit hInstance aus WinMain identisch ist - ich gebe hInstance ja beim Dialogerstellen als Parameter mit an.

Hallo,
ich denke: hInstance von WinMain braucht man nicht unbedingt global mitschleppen.

GetModuleHandle(NULL); bringt's genauso

Martin Richter

Ich kann es langsam nicht mehr sehen:
http://blog.m-ri.de/index.php/2007/12/12/die-unsitte-immer-getmodulehandlenull-fuer-hinstance-in-createwindow-und-registerclass-zu-verwenden/

Nach eingehenden Versuchen habe ich rausgefunden, daß man auch einfach den hexzadezimalen Wert 0x400000 anstatt der hInstance Variable übergeben kann. Hiermit wird es unnötig, den hInstance Wert in einer globalen Variable abzuspeichern.

hInstance ist nur eine konstante mit dem Wert 0x400000 wollte ich damit sagen. Mach dir also am besten einfach ein define in der Art

#define HINSTANCE_VALUE 0x400000

und du musst dich mit diesem Problem niemehr herumschlagen

Jochen Kalmbach

bernibutt schrieb:

Nach eingehenden Versuchen habe ich rausgefunden, daß man auch einfach den hexzadezimalen Wert 0x400000 anstatt der hInstance Variable übergeben kann. Hiermit wird es unnötig, den hInstance Wert in einer globalen Variable abzuspeichern.

Bin mir nicht sicher, aber hast Du das schon mal unter Vista probiert?
Vor allem, wenn im Linker der Schalter /DYNAMICBASE aktiviert ist (was ab VS2008 default ist)?
Prinzipiell gilt die Regel: Verlass Dich nicht auf "Zufälle" sondern folge der Doku!

CStern

gestrichen

CStern

Martin Richter schrieb:

Ich kann es langsam nicht mehr sehen:
http://blog.m-ri.de/index.php/2007/12/12/die-unsitte-immer-getmodulehandlenull-fuer-hinstance-in-createwindow-und-registerclass-zu-verwenden/

hInstance in WinMain == GetModuleHandle(NULL)

habe ich was anderes geschrieben?

Für was er das verwendet, geht mir am A... vorbei.

Da muß ich CStern aber mal zustimmen, mein lieber Martin. Es ist selbsterklärend, daß man in einer Dll nicht GetModuleHandle(0) aufruft, wenn man die Instanz des Dll Moduls erhalten möchte. Das steht doch auch klip und klar in der Dokumentation und ist gänzlich logisch. Hieraus schlußfolgern zu wollen, daß man GetModuleHandle(0) generell nicht verwenden sollte, halte ich für völlig fahrlässig.

Einen schönen Feierabend!

CStern

bernibutt schrieb:

Da muß ich CStern aber mal zustimmen, mein lieber Martin. Es ist selbsterklärend, daß man in einer Dll nicht GetModuleHandle(0) aufruft, wenn man die Instanz des Dll Moduls erhalten möchte. Das steht doch auch klip und klar in der Dokumentation und ist gänzlich logisch. Hieraus schlußfolgern zu wollen, daß man GetModuleHandle(0) generell nicht verwenden sollte, halte ich für völlig fahrlässig.

Einen schönen Feierabend!

Vielen Dank, wünsch ich Dir auch.
Ich komme ja von einer Prog-Sprache, da kennt man WinMain und hInstance ja gar nicht und muss trotzdem an die Handles kommen.

Diese Schulmeistereien gehen mir langsam auf den Sack.
Insbesondere: Bisher hat niemand in meiner Umgebung jemals eine Windowclass global registriert! sondern immer abhängig von der App und bitte bitte immer brav: UnregisterClass() für die App verwenden.

Martin Richter

Ich würde GetModuleHandle(0) grundsätzlich nicht verwenden, deshalb halte ich diesen Tipp auch nicht für OK.
Das Handle für das aktuelle Modul kann man sicherer bekommen (siehe Artikel)...

Grund: Auf einmal kommt man auf die Idee und verwendet Code wieder in anderen Modulen (soll ja vorkommen ), und dann? Dann steht GetModuleHandle(0) und benutzt diesen Code in einer DLL!
Gutes Programmieren heißt auch Code so zu schreiben und zu nutzen, dass man ihn gefahrlos und mit möglichst wenig nachdenken und Kontrolle wieder verwenden kann.

Wenn ich auf diese Idee kommen, denke ich doch natürlich daran, dies entsprechend abzuändern! Wenn ich eine _dllspec(dllexport) Funktion aus einem Modul ins Hauptprogramm auslagere, muss oder sollte ich das _dllspec(dllexport) ja auch entfernen. Es ist doch ganz klar, daß man den Code dann an diesen Stellen anpasst. Ich kann diese Ansicht leider nicht teilen!

CStern

Martin Richter schrieb:

Ich würde GetModuleHandle(0) grundsätzlich nicht verwenden, deshalb halte ich diesen Tipp auch nicht für OK.
Das Handle für das aktuelle Modul kann man sicherer bekommen (siehe Artikel)...

Grund: Auf einmal kommt man auf die Idee und verwendet Code wieder in anderen Modulen (soll ja vorkommen ), und dann? Dann steht GetModuleHandle(0) und benutzt diesen Code in einer DLL!
Gutes Programmieren heißt auch Code so zu schreiben und zu nutzen, dass man ihn gefahrlos und mit möglichst wenig nachdenken und Kontrolle wieder verwenden kann.

Bringt GetModuleHandle(NULL) gleich den hInstance der DLL, der exakt dem Wert in DLLMain zurück, entspricht. Der Progger der dass in seiner App eingesetzt hat ging also schon bewußt davon aus: Er braucht den Handle des Moduls.
Und behaupte dazu, dass der Parameter hInstance dieser beiden Prototypen gleichbedeutend sind:

int WinMain(HINSTANCE hInstance,
    HINSTANCE hPrevInstance,
    LPSTR lpCmdLine,
    int nCmdShow
);

BOOL WINAPI DllMain(
  HINSTANCE hinstDLL,
  DWORD fdwReason,
  LPVOID lpvReserved
);

Sowohl in WinMain als auch DLLMain erhalte ich via GetModuleHandle(NULL) exakt den Wert, den hInstance bzw. hinstDLL liefert! Und genau um das geht es. Man muss diesen Handle aus den Eintrittsfunktionen nicht global mitführen.

Ich sehe keine Probleme darin im BS auch einen Datenrückhalt für seine laufende App zu sehen und auch jederzeit darauf zurück zu greifen.
Wenn ich mir die zumeist ungenützeste Key-Value-Table der Welt namens ATOM ansehe ... ich nütze sie gerne und ausgiebig.

Martin Richter

Du irrst CStern!
GetModuleHandle(0) in einer DLL liefert hInstance der Windows EXE und nicht der DLL.
Siehe Doku:
http://msdn.microsoft.com/en-us/library/ms683199(VS.85).aspx
If this parameter is NULL, GetModuleHandle returns a handle to the file used to create the calling process (.exe file).

PS: Ich wollte keinen Flame War hier entfachen. Wenn sich jemand angegriffen fühlte durch meinen Ton, dann bitte ich um entschuldigung.

CStern

Martin Richter schrieb:

Du irrst CStern!
GetModuleHandle(0) in einer DLL liefert hInstance der Windows EXE und nicht der DLL.
Siehe Doku:
http://msdn.microsoft.com/en-us/library/ms683199(VS.85).aspx
If this parameter is NULL, GetModuleHandle returns a handle to the file used to create the calling process (.exe file).

PS: Ich wollte keinen Flame War hier entfachen. Wenn sich jemand angegriffen fühlte durch meinen Ton, dann bitte ich um entschuldigung.

Ich fühle mich nicht angegriffen und es gibt keinen Grund für Entschuldigungen. Sondern: Warum nicht mal ne Diskus, die sich gewaschen hat Solange das alles nur um die Sache geht. Meinetwegen können sogar die Fetzen fliegen. Nur persönlich darfs nicht werden und in Beleidigungen ausarten.

Wenn jemand den Code tatsächlich von einer App in eine DLL überträgt, so hast DU RECHT! hInstance einer DLL ist nicht gleich GetModulehandle() und ich habe mich geirrt. Also: In einer DLL ist GetModuleHandle(NULL) böse ...
oder doch nicht? Dient eine DLL nicht der EXE die sie anzieht? ... *wegduck*