Vergabe von ID's und deren Auswirkung

[Luckie]

Es geht hier wohl nicht um die IDs von Datensätzen, sondern von die IDs von Windowssteuerlementen. Ich denke, der Hinweis mit WM_USER dürfte hier nicht zutreffend sein, da mit den IDs Steuerelemente benannt werden und keine Nachrichten. Warum dieses Steuerelement jetzt aber "geblinkt" hat, kann ich mir aber auch nicht so recht erklären und wenn dann nur mit einer ziemlich schrägen Erklärung und so schräg kann man eigentlich gar nicht programmieren, so dass für mich diese Erklärung eigentlich ausscheidet.

Ich persönlich fange eigentlich bei hundert an zu zählen. Und wenn ich mehrere toplevel Fenster habe, dann bekommt das Hauptfenster die ID 100 und die Steuerelemente auf diesem die IDs 101 bis 199. Das zweite Fenster bekommt die ID 200 und die Steuerelemente auf diesem die IDs 201 bis 299 und so weiter.

[Union]

Vielleicht werden diese IDs ja auch irgendwo in seinem Eventhandler-Code abgefragt. Und dort kann dann sehr wohl was schieflaufen.

[EWeiss]

Zitat von Luckie:

Es geht hier wohl nicht um die IDs von Datensätzen, sondern von die IDs von Windowssteuerlementen. Ich denke, der Hinweis mit WM_USER dürfte hier nicht zutreffend sein, da mit den IDs Steuerelemente benannt werden und keine Nachrichten. Warum dieses Steuerelement jetzt aber "geblinkt" hat, kann ich mir aber auch nicht so recht erklären und wenn dann nur mit einer ziemlich schrägen Erklärung und so schräg kann man eigentlich gar nicht programmieren, so dass für mich diese Erklärung eigentlich ausscheidet.

Ich persönlich fange eigentlich bei hundert an zu zählen. Und wenn ich mehrere toplevel Fenster habe, dann bekommt das Hauptfenster die ID 100 und die Steuerelemente auf diesem die IDs 101 bis 199. Das zweite Fenster bekommt die ID 200 und die Steuerelemente auf diesem die IDs 201 bis 299 und so weiter.

Wäre ein Ansatzt habe mich auch so in etwa dran gehalten.
Das erklärt aber nicht das Phänomen.

Delphi-Quellcode:

PROP_IMAGE_BACK = 1;
GRID_IMAGE = PROP_IMAGE_BACK;

Funktioniert!

Delphi-Quellcode:

PROP_IMAGE_BACK = 1;
GRID_IMAGE = 1;

Funktioniert nicht!

obwohl beides letztendlich das gleiche Ergebnis liefert nämlich 1

gruss

[Elvis]

Sicher macht die WinApi das so. Die muss auch von allen Sprachen benutzt werden können, und ie ist aus den Dark-Ages der Programmier-Konventionen.
Wenn die das heute neu machen würden, würde das anders aussehen. Ups haben sie schon, heißt .Net. und da gibt es keine prökeligen Nachschlage Indizes...


Um mein Unverständnis verständlicher auszudrücken:
Warum gebe ich irgendeiner Methode eine Zahl auf etwas mit dem ich gerade arbeitete, damit die das dann auch nachschlagen kann, anstatt das Objekt zu selbst übergeben. Vor allem hätte dann die Methode einen Parameter vom richtigen Typen, so dass man kein Label übergeben kann, wenn da eine Liste rein muss.

Den Sinn dahinter hatte ich schon verstanden, nur nicht wie sinnvoll das ist.

[Luckie]

Jungs, jetzt haltet mal die Bälle flach. Er benutzt offensichtlich die VCL nicht, dort werden ja auch keine IDs benötigt - zumindest sieht sie der Programmierer nicht. Wenn man ohne die VCL und mit der API direkt arbeitet, ist es einfacher die Steuerelemente über die ID anzusprechen. Dann muss man sich keine hunderte von Handels in Variablen merken und kann die Steuerelemente mit diesen eindeutigen IDs ansprechen.

[EWeiss]

Wie sieht es denn jetzt mit meiner Frage aus..
Warum funktioniert die ID mit gleicher Nummer nur wenn man sie über Unterschiedliche Variablen anspricht ?
Obwohl letztendlich die Nummer und nicht der Name ausgewertet wird.

gruss

[Phoenix]

Zitat von EWeiss:

Delphi-Quellcode:

PROP_IMAGE_BACK = 1;
GRID_IMAGE = PROP_IMAGE_BACK;

Funktioniert!

Delphi-Quellcode:

PROP_IMAGE_BACK = 1;
GRID_IMAGE = 1;

Funktioniert nicht!

Einzige mir sinnige Möglichkeit ist, dass hier auch ein schreibender Zugriff auf die Speicherstelle passiert, und in der Methode irgendwo der Wert verändert wird, was nicht mehr funktioniert wenn die eine 1 in einer anderen Speicherstelle steckt als die andere.

Wenn solch ein Phänomen auftritt und man schon andere nach der Ursache frageb muss in Code den man selber geschrieben hat sollte man allerdings besser sein Konzept in Frage stellen und anfangen Objektorientiert zu arbeiten.

[EWeiss]

Zitat:

in Frage stellen und anfangen Objektorientiert zu arbeiten

Was ihr immer mit eurem Objektorientiert habt.
Ich sehe aber kann mir wohl niemand plausiebel erklären.. trotzdem das ihr Objektorientiert arbeitet..

Also Eigentor geschossen!
Soviel zu Objektorientiert

PS:

Zitat:

muss in Code den man selber geschrieben hat

Wer soll das sonst geschrieben haben

gruss

[Phoenix]

Wenn man ID's durch die Gegend schiess ist das prozedural Runtergebolzt. Oder auch Spagetthicode. Das das irgendwann knallt ist vorhersehbar. Und wie gesagt: Die einzige Ursache kann hier ein schreibender Zugriff sein - solange Du nicht mehr Code zeigst als zwei Zuweisungen die nicht passen können wir auch nur das hier machen:

[Luckie]

Zitat von Phoenix:

Wenn man ID's durch die Gegend schiess ist das prozedural Runtergebolzt.

Die Aussage ist Unsinn. Ich glaube, hier hat noch niemand verstanden wozu diese IDs benutzt werden. Es wird eine Schaltfläche mit CreateWindow erstellt. Jetzt muss ich im Code auf dies Schaltfläche zugreifen können, unabhängig davon, ob ich objektorientiert arbeite oder nicht. Dazu habe ich zwei Möglichkeiten: 1. Ich kann mir das Handle merken, welches mir die Funktion zurückgibt. 2. Ich kann dem Steuerelement im Funktionsaufruf eine eindeutige ID geben, über die ich dann auf das Steuerelement zugreifen kann. Welche Methode man bevorzugt ist Geschmackssache. Wobei die erste Möglichkeit nicht möglich ist, wenn man seine Steuerelemente mit einem Ressourceneditor erstellt und nicht zur Laufzeit. Ob ich den restlichen Code jetzt objektorientiert erstelle oder prozedural, spielt keine Rolle. In beiden Fällen muss ich meine Steuerelemente irgendwie ansprechen können.