Vergabe von ID's und deren Auswirkung

[EWeiss]

Zitat:

Zitat von Luckie (Beitrag 1102008)

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]

Ich kenne sowas eigentlich gar nicht.
Wobei ich versuche möglichst gar keine Konstanten im Code zu haben. Denn wie in der Physik ist das oft ein Zeichen, dass man Lücken in der Theorie hat. :mrgreen:

Warum brauchst du überhaupt IDs für Controls oder andere Objekte?
Das wirkt als würdest du an irgendeiner stelle entweder nicht Objekt-Orientiert arbeiten, oder es sogar absichtlich platt-kloppen.

Da es aber nunmal schon so ist wie es ist, kannst du dirja in deinem Projektordner eine XML-Datei packen, in der alle diese komischen Keys gelistet sind.
Aus der kannst du dann immer den Delphi Code erzeugen, der sie dann als Konstante listet. Der Code, der dir den Delphi code erzeugt, könnte auch meckkern, wenn es zu Duplikaten kommt.
Wenn du das auf diese etwas plumpe Art wirklich willst. Denn was du da hast sind dann einfach nur Cardinals, die sagen rein gar nix aus.
Was du vllt willst sind enums, deren Feldern du Werte zuordnest.

Delphi-Quellcode:

type TControlIds =
(
  IntroLabel = 100, // Informations Label
  AeroButton= 101, // Aero Button
  FlipNotes = 102, // Noten Umdrehen
  Drum = 103, // Drum Liste
  Instrument = 104, // Instrumenten Liste
...
);

Aber für's nächste Projekt solltest du versuchen auf Objekte nciht über irgendeine ID zuzugreifen, sondern das Objekt selbst weiter zu reichen und direkt auf ihm zu arbeiten. Sonst nimmt man eine halbwegs moderne Sprache, und benutzt sie wie Pascal auf CPM+.

Edit: Ganz vergessen, dass Delphi-Enums global sind. Also nicht durch den Typen benutzten werden. Mussu also so einen grausigen Präfix nutzen, wie man es ja kennt (Hast ja jetzt auch einen).

[EWeiss]

Verstehst du den Sinn einer ID nicht?
Das ist kein WM_MESSAGE sondern wie Luckie schon gesagt hat eine identifizierung um zum Beispiel
ein Object eindeutig zuordnen zu können.

Was hat das mit Objekt-Orientiert zu tun?
Das ist allgemein Standard und wird auch in C++ als Standard so gehalten wenn es um WinAPI Code geht.
Hier gibt es kein Control das funktioniert ohne eine eindeutige ID_

PS:
Habe dir mal ein Bild erstellt das du sehen kann warum man eine ID verwendet..
Wenn das nicht Objekt-Orientiert ist dann weiss ich auch nicht!

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:

Zitat von EWeiss (Beitrag 1102012)

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. :gruebel:
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: :glaskugel:

[Luckie]

Zitat:

Zitat von Phoenix (Beitrag 1102032)

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.