Ich schreibe gerade ein Programm zu Spannungssteuerung über den CAN-Bus. Hierbei wurde eine DLL zur Verfügung gestellt. Jetzt habe ich eine weitere DLL erstellt, die auf die Funktionen der mitgelieferten DLL zugreift. Das funktioniert auch alles. Ich habe mir eine Variable definiert, die das handle der DLL aufnehmen soll:

HINSTANCE handleDLL;	// to store the handle of DLL

Verfahre dann, nach dem Standard, mit GetProcAdress() mir den Funktionszeiger der Funktion zu holen, die aus der mitgelieferten DLL geladen werden soll. Hier mal exemplarisch eine der Funktionen aus meiner DLL:

DWORD ActualCurrent (DWORD ident, BYTE Channel)
{
	handleDLL = LoadLibrary (TEXT("PCAN_PCI.DLL"));

	if (handleDLL != NULL)		
	{
		CAN_Schreiben = (PCAN_Write) GetProcAddress (handleDLL, "CAN_Write");

		if (CAN_Schreiben != NULL) 
		{
			CANMsg.MSGTYPE = 0;
			CANMsg.LEN = 3;          
			CANMsg.ID = ident;  

			CANMsg.DATA[0]= 0x90 + Channel;  
			return (CAN_Schreiben(&CANMsg));
		}
		else return (66);

		// free the DLL 
		//
		FreeLibrary(handleDLL);
	}
	else return (66);
}

Nun hatte ich aber zuvor für das handle der DLL folgende Variable angelegt:

HANDLE handleDLL;	// to store the handle of DLL

was mir aber beim kompilieren prompt eine Fehlermeldung in Zeile 7, vom Typ:

Fehler1 error C2664: 'GetProcAddress': Konvertierung des Parameters 1 von 'HANDLE' in 'HMODULE' nicht möglich

eingebracht hat. Meine Frage wäre jetzt warum ich für das handle eine Variable vom Typ HINSTANCE erzeugen muss und wo genau der Unterschied der beiden handle-Datentypen liegt. Ich war der Meinung HANDLE sei der Datentyp um Objekt-handels aufzunehmen.

Ich hoffe ich habe alles richtig geposted und zusammengefasst.
Viele Dank im Voraus
lg

Genauso wie verschiedene Klassen verschiedene Memberfunktionen haben, gibt es auch für verschiedene Handle-Typen verschiedene "passende" Funktionen. Wenn du ein Handle an eine unpassende Funktion übergibst, dann wird u.U. grosser Quargel dabei rauskommen. Im günstigsten Fall meldet die Funktion einfach nur einen Fehler, im ungünstigsten Fall passiert etwas "schlimmes".

Was man noch dazusagen sollte: es gibt nicht für jedes unterschiedliche "Ding" in Windows einen eigenen Handle-Typ. Sogesehen sind Handles also vergleichbar mit Zeigern auf abstrakte Basisklassen in C++.

HANDLE ist der Typ für KERNEL Handles. Beispiele für Kernel-Objekte sind Files, Device-Handles, Mutexen, Events, Threads, Prozesse.
Die passenden Funktionen für solche Objekte sind z.B.
* CloseHandle
* WaitForSingleObject/WaitForMultipleObjects(Ex)
* ReadFile/WriteFile
* DeviceIoControl
...

Dann gibt es z.B. HGDIOBJ, der Handle Typ der für (wie der Name vermuten lässt) GDI Objekte verwendet wird.
Das können Pens, Brushes, Fonts etc. sein.
Passende Funktionen sind z.B.
* DeleteObject
* SelectObject
...
Wenn du ein HGDIOBJ z.B. an CloseHandle übergibst, wird Mist dabei rauskommen.

Weitere Typen wären HWND (Fenster), HDC (Device Context), HKEY (Registry Keys), HMONITOR ("Monitore"), HWINSTA (Window Stations) etc.
Die meisten dieser Typen sind leider nur Typedefs auf "HANDLE", was aber nicht heisst dass man sie mit den für "HANDLE" passenden Funktionen verwenden kann.

Weiters gibt es auch noch einige Dinge die als "HANDLE" rumgereicht werden, aber trotzdem z.B. nicht mit CloseHandle geschlossen werden dürfen. z.B. Find-Handles (-> FindFirstFile, FindNextFile, FindClose).

Und dann gibt es eben HMODULE und HINSTANCE.
In neueren Versionen ist ein Instance-Handle (HINSTANCE) immer auch ein gültiges Module-Handle (HMODULE). Warum das jetzt so ist, und warum es in älteren Windows Versionen (-> Windows 3.1) anders war führt jetzt etwas zu weit.

------

Nochwas: die Handle Typen unterscheiden sich "eigentlich" nur durch ihre Bedeutung. Letztlich sind alles nur einfache Zeiger (bzw. Integers mit der gleichen Breite wie ein Zeiger). Auch wieder analog zu C++: Zeiger auf verschiedene Typen sind "intern" auch alle "gleich", bloss ihre Bedeutung unterscheidet sich. Die Unterscheidung verschiedener Typen macht aber natürlich trotzdem Sinn, eben weil ein X kein U ist, und auch nicht als U behandelt werden sollte.

Ein Windows-Handle ist eher eine Art ID, weder ein "richtiger" Pointer noch eine
"richtige" Kennziffer. Es ist halt da und man kann es verwenden. Solche Konstrukte
entstehen wenn Entwicklung nicht koordiniert wird.

Solche Konstrukte
entstehen wenn Entwicklung nicht koordiniert wird.

わ was?

Bei MS weiß die linke nicht was die rechte programmiert. Und es gibt viele
Abteilungen, alles abgeschottet. Ein "Händl" ist da der "kleinste gemeinsame
Nenner" irgendwas herumzureichen.

was brabbelst du da für müll? wieder zuviel gesoffen oder was?

Problem ? Leg Dich wieder hin.

Sollte Windows mal Open Source werden wird das das Ende der Open Source sein.
Die Jungs haben sich totgelacht.

Bei MS weiß die linke nicht was die rechte programmiert. Und es gibt viele
Abteilungen, alles abgeschottet. Ein "Händl" ist da der "kleinste gemeinsame
Nenner" irgendwas herumzureichen.

rofl. wenn du zu doof für windoof bist, dann komm bitte nich ins WinAPI forum, kthx.

Das win32-API entspricht im Unterhaltungswert einem durchschnittlichen
MAD-Heftchen, das wirst Du wohl kaum ernsthaft bestreiten wollen.

Ich weiß nicht, ob das bei Linux etc. wirklich "besser" ist (was immer das
bedeuten könnte), aber so ein Gegurke mit allem möglichen historisch gewachsenen
Unkräutern sieht man selten. Eins dieser Unkräuter sind die ominösen Handles.
Ohne ständiges casten geht da kaum etwas. Sinnvoll ? Na ja ...

Das win32-API entspricht im Unterhaltungswert einem durchschnittlichen
MAD-Heftchen,

falsch!

Guuds Nächtle.

Wenn du nicht begreifst warum kann ich dir auch nicht helfen.

danke für die schnellen Antworten!
Ich denke ich habs jetzt verstanden
Ich kahm da wohl mit den Objekt- und den Instanz-handles ein Bischen durcheinander...

@Scheppertreiber: Warum bist du von den handles nicht so begeistert? Schien mir doch bisher immer eine recht clevere Sache zu sein.

lg

CreateWindow liefert mir ein Fensterhandle. Nun will ich das Fenster wieder loswerden. Naheliegend ist, das es zu diesem Zweck geschlossen werden muß. Aber was jetzt? Das Fenster oder das Handle oder beides?

Warum DestroyWindow (dann verschwindet vielleicht das Fenster aber das Handle nicht). Vielleicht CloseHandle (hab ja ein Handle)? Oder eben DeleteObject (hab ja OOP und so und vielleicht verschwinden dann Handle und Fenster zusammen).

Ich behaupte mal, daß die Unzahl an Handles und Datentypen in der WinAPI einfach nur sowas wie "Typsicherheit in C zur Kompilierzeit" simulieren sollen.