Handles und Treads

[Getox]

Guten Morgen,

Ich schreibe zur Zeit an einem Programm, wo ich das erste mal mit einem Tread arbeiten möchte. Um die Grundlagen des Treads zu erlernen, beschäftige ich mit dem Tutorial auf Delphi-Treff. http://www.delphi-treff.de/tutorials...ds/einleitung/

Da wird des öfteren von Handles geredet. Auch so ist mir der begriff desöfteren über den Weg gelaufen. Also habe ich mich auf die Suche gemacht. Gestoßen bin ich dann auf folgenden tread hier aus dem Forum:
http://www.delphipraxis.net/84848-handles.html

Eigentlich wollte ich erst eine Antwort in diesem Thema schreiben, aber dann wäre ich vermutlich angemeckert worden, weil ich einen 5 Jahre alten Tread auspacke

Also. Handles sind ja quasi IDs für Fenster. In dem Abschnitt, den man nur lesen soll, wenn man verwirrt werden will, stand, dass Handles aber auch ohne Fenster gibt.

Ja ich bin jetzt leicht verwirrt. Nun habe ich ein paar Fragen.
- Ist es wichtig, dass ich Handles richtig verstehe, bevor ich mich weiter um Treads kümmere?
- Sind die Handles von Threads dann quasi die ID eines Treads?
- Ich weis in dieser Hinsicht icht was ich mir alles anschauen muss und so und das verunsichert mich grade etwas.

Ich weis gerne was ich tu und ich glaube, in diesem Sinne sollte ich mich doch schon auch mit solchen DIngen auseinandersetzen.

[Zacherl]

Unter Windows gibt es sehr viele Objekte, zu denen es ein Handle geben kann (Prozesse, Threads, Windows, GDI Resourcen, etc.). Handles stellen im Grunde genommen eine Form des einfachen Zugriffs auf systemverwaltete Resourcen (z.b. Kernel Objekte) dar, auf die man normalerweise vom Usermode aus nicht direkt zugreifen kann.

Ein paar wichtige Eigenschaften von Handles:

• ein Handle gillt (in der Regel) nur in dem Prozess, in dem es per WinAPI erstellt oder geöffnet wurde
• die Meisten Handles können neben dem Objekt, das sie beschreiben, auch Zugriffsrechte speichern

Ein Handle ist somit viel mehr, als eine einfache ID. Im Gegenteil sogar, ist ein Handle nicht eindeutig. Jeder Thread hat eine ThreadID (z.b. die Nummer 500), die Systemweit gültig ist und den Thread eindeutig beschreibt. Über OpenThread() kann man sich nun über die ID ein Handle des Threads (z.b. die Nummer 1000) beschaffen, mit dem man dann Operationen wie SuspendThread() oder TerminateThread() ausführen kann. Ruft man jetzt aber z.b. ResumeThread(1000) aus einem anderen Prozess aus, wird die Operation fehlschlagen, da das Handle 1000 nur in dem Prozess gültig ist, in dem es erstellt bzw. geöffnet wurde.

[Bummi]

Handles gibt für ziemlich viele Objekte in Windows, das was dahinter liegt sind 4 Byte als Longword.
Im Kontext sind das dann z.B.
HWND = type LongWord; HRGN = type LongWord;HBITMAP = type LongWord;HBRUSH = type LongWord; etc.
(Du kannst ja mal in die Windows.pas schauen) oder hier http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

[Aphton]

Für den Anfang reicht es aber total aus, nen Handle mehr oder wniger als ID zu sehen - zum besseren Verständnis.

Noch etwas - es heißt Threads, nicht Treads

[Getox]

Ich fasse Zacherl noch mal so zusammen wie ich es verstanden habe:
Handles sind da, um bestimmte Aktionen an etwas auszuführen. Das Fenster, der Thread oder was auch immer hat schon eine eigene ID. Das ist aber egal, da man im Normalfall nicht die Berechtigung hat, Aktionen auszuführen, welche durch das Handle ermöglicht werden. Das Handle selber bekommt auch eine ID, ist aber im Gegensatz zu den dazugehörigen "Objekten" nur von einem Prozess aus ansprechbar.

Ist das so ungefähr korrekt? (Zusammenfassen finde ich toll, da man sich dann noch mal Gedanken drüber macht und im Nachhinein überprüft werden kann, ob ich es wirklich verstanden habe )

Von Bummi habe ich bis zum ersten "Longword" alles verstanden glaube ich. Danach ist das alles irgendwie Bahnhof o.O

@Aphton
Das es Thread heißt, war mir eigentlich bewusst... ich hab erst gedacht, das wäre nur in der Überschrift falsch. Aber als ich dann den ersten post gesehen habe dachte ich nur "WTF! Was machst du da, Gehirn???". Wie dem auch sei, ich habe mich schon selber ausgelacht und ich hoffe sowas passiert mir nicht zu oft... aber es ist ja auch Freitag und noch früh und so.

BTW ist das da L in deinem Avatar? <3

[terence14]

...und dazu habe ich auch eine Frage

Manchmal ist es doch notwendig, daß man folgendes
in der MainUnit des Programmes definieren muß:

Delphi-Quellcode:

const WM_ICONTRAY = WM_USER + 1;  {-warum +1-}

procedure TrayMessage(var Msg: TMessage); message WM_ICONTRAY;

Klar, es ist irgendeine Identifikationsnummer für
Windows Messages. Nun zur Frage.

Wovon hängt der Wert ( hier +1) ab, den ich hinzufügen muß?
Manchmal liest man in Programmbeispielen auch +99.
Das verwirrt mich doch ziemlich! Welche Fehler kann man
hier denn machen?

MfG,
terence

[Medium]

@Handles: Wenn man sich den Begriff einfach mal ins Deutsche übersetzt, kommt das dem Zweck schon sehr nahe: Griff! Ein Handle ist einfach ein "Anfasser" für System-Objekte, wobei am Handle selber zunächst nicht erkennbar ist, um was für ein Objekt es sich dahinter handelt. Es ist einfach nur eine systemweit eindeutige Nummer, bei denen Windows bei Verwendung diverser API-Funktionen dann weiss, auf was diese Funktion anzuwenden ist.

@Messages: Alle Messages ab WM_USER sind zur freien Verwendung. Es steht dem Entwickler völlig frei, was er zu WM_USER hinzu addiert.

[Bernhard Geyer]

Wenn es sich um Handles um GDI-Ressourcen handelt. Auf diese darf nur im Thread darauf zugegriffen werden der es auch erzeugt hat.

[Getox]

Ich glaube wenn das einzige was mir zu "GDI-Ressourcen" einfällt das Wort "Tiberium" ist, sollte ich auch noch mal da schauen was das ist o.O

[Aphton]

Zitat von Getox:

BTW ist das da L in deinem Avatar? <3

Jupp ^^

Zitat von terence14:

const WM_ICONTRAY = WM_USER + 1; {-warum +1-}

Was hier geschieht, ist, dass du eine Vereinbarung, ne Definition machst. Du sagst, WM_ICONTRAY hat genau "diesen Wert". Dieser Wert muss eindeutig sein. Alles unterhalb WM_USER (1024) ist bereits vergeben, deshalb nimmt man beliebige Werte drüber.
Bsp. die Ok sind:

Delphi-Quellcode:

const 
  WM_MYMESSAGE1 = WM_USER + 1;
  WM_MYMESSAGE2 = WM_USER + 2;

Nicht OK:

Delphi-Quellcode:

const 
  WM_MYMESSAGE1 = WM_USER + 1;
  WM_MYMESSAGE2 = WM_USER + 2;

  WM_MYOTHERMESSAGE = WM_USER + 1;

Man kann nämlich per SendMessage / PostMessage (auch) prozessübergreifend "Nachrichten" schicken. Der Empfänger kann nun zu jeder Nachricht "reagieren".
Bsp. die Message 1025 (WM_USER + 1 = WM_MYMESSAGE1) wird empfangen, er kuckt nach, ob es zu dieser Msg nen Event gibt. Ist er nicht eindeutig, kommts hier schon zu Problemen