Vergabe von ID's und deren Auswirkung

[EWeiss]

Letztens ein seltsames Phänomen
Ich vergebe meine Id's spontan und in verbindung stehend mit der Funktion für die Sie gedacht ist.
So wie diese hier.

Delphi-Quellcode:

  ID_LABEL_INTRO           = 100;  // Informations Label
  ID_AEROBUTTON            = 101;  // Aero Button
  ID_FLIPNOTES             = 102;  // Noten Umdrehen
  ID_DRUM                  = 103;  // Drum Liste
  ID_INSTRUMENT            = 104;  // Instrumenten Liste
  ID_VL                    = 105;  // VL Liste
  ID_EFFECTS               = 106;  // Effects Liste
  ID_LABEL_GENRE           = 107;  // Informations Label
  ID_GLASS_OPACITY_LABEL   = 108;  // Informations Label
  ID_TRACK_OPACITY         = 109;  // Trackbar Transparent
  ID_AEROCRYSTAL           = 110;  // Aero Check Button
  ID_AEROBLUR              = 111;  // Aero Blur Button
  ID_LINEVERT              = 112;  // Einfache Linie
  ID_AERODISABLE           = 113;  // Global Aero Disable
  ID_TRACK_BLURLEVEL       = 114;  // Trackbar BlurLevel
  ID_VERSION               = 115;  // Versions Info
  ID_BTN_ABOUT             = 116;  // About Button

Letzten's lasse ich ein Lied laufen und muss feststellen das plötzlich einer meiner
Button anfängt zu blinken jetzt war ich sehr verwundert denn das passierte nur wenn das spezielle aufgerufen wurde.
Bekam schon wieder die Krise da ich einfach nicht lokalisieren konnte woran das liegen könnte.

Nach einiger Überlegung kam ich zu dem Schluss das es unter Umständen mit meiner vergabe der ID's zu tun haben
könnte alles durchsucht ob vielleicht doppelte Einträge vorhanden waren. Na ja nix.
Dann bin ich hingegangen und habe einfach mal alle ID's um ein 1000 faches höher gesetzt.
Und siehe da plötzlich war das problem beseitigt.
Kein Blinken mehr.

Wie laßt ihr euch leiten bei der vergabe der ID's habe immer wieder ein.. zwei kleine Probleme hier.
Noch ein Beispiel..

Erster Eintrag.

Delphi-Quellcode:

PROP_IMAGE_BACK     = 1;
SkinEngine.SetImageProperty(FHPanel, PROP_IMAGE_BACK, Img);

Delphi-Quellcode:

GRID_IMAGE = 1;
SKAERO_SetImageProperty(FHGrid, GRID_IMAGE, Img);

Wohl bemerkt die zweite ist nicht global ausgelegt.
Und Funktioniert nicht.Kein Object wird gezeichnet.

Das hingegen funktioniert einwandfrei

Delphi-Quellcode:

PROP_IMAGE_BACK     = 1;
GRID_IMAGE = PROP_IMAGE_BACK;

Also ehrlich das ist schon sehr konfus das ganze.
Die übergabe von ID's macht das Programm meines erachtens extrem anfällig für Fehler
vor allem dann wenn man sie wie in dem Beispiel oben nicht identifizieren kann.

Wer garantiert das nicht just in dem Moment meine Message mit denen der WindowsAPI kollidieren?

Meine Frage nochmal wie Handhabt ihr das mit der vergabe von ID's und wo steht man auf
der sicheren Seite?

gruss

[jfheins]

Welche ID's?
Windows Message.ID's? Dann guck dir mal WM_USER an.

[EWeiss]

Zitat:

Zitat von jfheins (Beitrag 1101996)

Welche ID's?
Windows Message.ID's? Dann guck dir mal WM_USER an.

Du verstehst schon auf was ich hinaus will oder?
Besonders den Sinn hinter meiner Frage.

gruss

[Phoenix]

Du verstehst schon die Antwort? Besonders den Sinn hinter dem Hinweis auf WM_USER?

[s.h.a.r.k]

Deine IDs definieren ja Messages oder? Wenn ja, dann sollten diese tunlichst überhalb von der Konstante WM_USER angesiedelt werden, da es eben sonst zu Kollisionen kommt. Macht das halt so:

Delphi-Quellcode:

  ID_LABEL_INTRO = WM_USER + 100; // Informations Label
  ID_AEROBUTTON = WM_USER + 101; // Aero Button
  ID_FLIPNOTES = WM_USER + 102; // Noten Umdrehen
  ID_DRUM = WM_USER + 103; // Drum Liste

Alles was kleiner als WM_USER ist, gehört einfach Windows :)

[jfheins]

Zitat:

Zitat von EWeiss (Beitrag 1101998)

Du verstehst schon auf was ich hinaus will oder?
Besonders den Sinn hinter meiner Frage.

gruss

Nein, ich habe keine Ahnung, welche ID's du da hast und wofür du die brauchst. Und erst recht nicht warum auf einmal irgendwelche Buttons blinken. Deshalb habe ich ja auch nachgefragt.

Aber gut, ich will natürlich gerne auf deine Frage antworten:

Zitat:

Meine Frage nochmal wie Handhabt ihr das mit der vergabe von ID's und wo steht man auf
der sicheren Seite?

Ich lasse meine ID's meistens automatisch vergeben. Dazu lege ich grundsätzlich in jeder MySQL Tabelle als erstes eine Spalte "id" mit einem Integertypen an. Diese wird dann auf auto_increment gesetzt, sodass beim Einfügen neuer Datensätze automatisch eine neue ID generiert wird.
Kollisionen hatte ich bisher keine, das mit dem incrementieren funktioniert zuverlässig. :stupid:

Aus den blinkenden Buttons habe ich aber geschlossen, dass es sich um Windows Message ID's handeln könnte. Und in diesem Fall ist der Hinweis auf WM_USER ernstzunehmen ;)

[Union]

WM_USER

Range Meaning
0 through WM_USER–1 Messages reserved for use by the system. [/MSDN]

[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:

Zitat von Union (Beitrag 1102005)

WM_USER

Range Meaning
0 through WM_USER–1 Messages reserved for use by the system. [/MSDN]

Das ist mir schon klar.
Wer garantiert dir aber das die Messagen übrigends WM_USER ist FALSCH
dann nicht doch mit anderen kollidieren.

Das ist wenn ihr es schon so genau nehmt Korrekt!
Ein vielfaches von ...
WM_USER and WM_APP

gruss

[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.

[EWeiss]

Zitat:

Zitat von Luckie (Beitrag 1102036)

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.

Gut beschrieben :thumb:
Deshalb auch!

Zitat:

Was ihr immer mit eurem Objektorientiert habt.:gruebel:

Zur besseren verständigung..

Delphi-Quellcode:

function GetMainItem(hOwner: HWND; UseID: integer): integer;

function TSkinEngine.GetMainItem(hOwner: HWND; UseID: integer): integer;
begin

  Result := GetDlgItem(hOwner, UseID);
end;

Über meine ID kann ich jetzt zu jederzeit mein Handle abfragen über die Spezifizierte ID_

Objektorientiert oder nicht ?
Noch näher dran geht wohl nicht! Spagetthicode na ja .. Warum auch nicht. Ist mal was anderes und nicht so fade.

gruss

[FredlFesl]

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!

obwohl beides letztendlich das gleiche Ergebnis liefert nämlich 1

gruss

Gib mal Code, wo das nicht funktioniert. Kann ja gar nicht sein.

[Satty67]

Grob gesagt, funktioniert es nicht, wenn Du eine Konstante verwendest. Also einen Wert der durch falschen Speicherzugriff im Programmablauf überschrieben werden könnte.

Ich denke die Werte Deiner Konstanten hast Du schon kurz vor Verwendung mit dem Debugger überprüft.

Letztlich sind die geposteten Codezeilen syntaktisch korrekt, was Du selber weist, aber als Außenstehender wird man damit ohne weiteren Codeeinblick unmöglich auf den Fehler schließen können.

[Jumpy]

OT?: Mal wieder doof nachgefragt. Woher weiß der Compiler eigentlich wenn man eine Konstante macht, was das für ein Typ ist?

const Willi = 1;

Ist Willi nun Integer, oder Byte,...

/OT.

[Namenloser]

[OT]

Zitat:

Zitat von Jumpy (Beitrag 1102245)

OT?: Mal wieder doof nachgefragt. Woher weiß der Compiler eigentlich wenn man eine Konstante macht, was das für ein Typ ist?

const Willi = 1;

Ist Willi nun Integer, oder Byte,...

/OT.

Weiß er nicht. Solche Konstanten werden daher auch als „untypisiert“ bezeichnet. Sie funktionieren vereinfacht gesagt, indem der Compiler im Quellcode nach „Willi“ sucht und es durch „1“ ersetzt.
Bei typisierten Konstanten ist es anders:

Delphi-Quellcode:

const Willi: integer = 1;

In diesem Fall verhält sich Willi wie eine globale Variable (und kann auch zur Laufzeit manipuliert werden über Pointer oder einen Compilerschalter, der änderbare Konstanten erlaubt).
[/OT]