Hallo zusammen.
Ich habe vor kurzem angefangen mich in Delphi einzuarbeiten, und muss mich fragen, ob ich bei der Verwendung von Enums irgendetwas falsch mache... Wenn ich zB folgenden Code habe, sagt der Compiler mir dass das nicht geht, weil foo und bar schon definiert sind.

Delphi-Quelltext    ausgeblendet	markieren
1: 2: 3: type TTest1 = (FOO, BAR); TTest2 = (FOO, BAR);

Dies ergibt für mich keinen Sinn, es sei denn die Enums haben keinen eigenen Namensraum.
Das nächste wäre dann dies:

Delphi-Quelltext    ausgeblendet	markieren
1: 2: 3: type TTest1 = (FOO, BAR); TTest2 = (FOO_, BAR_);

Meine IDE gibt mir bei der Autovervollständigung nun bei TTest1 nicht nur die eigenen Werte vor, sondern listet auch die Werte aller folgenden Enums auf. Packe ich den zweiten in einen eigenen type-Bereich funktioniert die Autovervollständigung normal.
Daher wundere ich mich, ob ich irgendetwas falsch mache, ob das ein Bug ist, oder ob Delphi was dies angeht einfach ein bisschen seltsam ist (in meinen Augen). Ich konnte bisher leider keine Antwort hierauf finden.
Ich benutze Embarcadero RAD Studio 2010.

Gruß,
exec

Hallo und im Forum!

Doch, das ist schon richtig so. Anders als bei z.B. Prism müssen auch die Werte der Enumeration eindeutig sein.

Delphi-Quelltext    ausgeblendet	markieren
1: 2: 3: type TConnectionKindCategories = (ckcFast, ckcSlow, ckcUnknown); TCarSpeeds = (csFast, csSlow, csUnknown);

Das ist eine Möglichkeit damit umzugehen, so wird es auch intern in Delphi gemacht. Zum Beispiel bei TBrushStyle --> bsClear, ... oder TFontStyle --> fsBold, ...

jaenicke hat folgendes geschrieben :

Hallo und im Forum!

Danke^^

Und auch danke für die schnelle Antwort. Gut, dann muss ich das so akzeptieren.

hat aber den Vorteil dass du dann nicht avar:=MyRealyLongEnum.Cool; schreiben musst, sondern nur avar:=rleCool;

Und immerhin meckert der Compiler, bei der Zuweisung.

Ich hatte letztens auch gerade den Fall, dass in zwei Enums die Werte gleich hießen. Da die Enums in verschiedenen Units waren, scheint das für Delphi kein Problem gewesen zu sein, aber Delphi meckerte dann bei meiner Zuweisung dass TTest1 und TTest2 nicht zusammenpassen.

baka0815 hat folgendes geschrieben :

Da die Enums in verschiedenen Units waren, scheint das für Delphi kein Problem gewesen zu sein

Ist es dann auch nicht. Auch Variablen und gleichnamige Klassen kannst du ja in unterschiedlichen Units problemlos deklarieren, da diese im Namespace der Unit existieren. (Sollte man nicht, klar, passiert aber bei fremden Komponenten.) Du kannst zur Klarstellung dann immer den Unitnamen davorsetzen. Das gilt auch für Werte in Enumerationen.

UnitA.pas    ausgeblendet	markieren
1: 2: 3: 4: 5: 6: 7: type TDemo = (MyValue, YourValue); var Demo: TDemo1; begin Demo := UnitB.MyValue;

UnitB.pas    ausgeblendet	markieren
1: 2: type TDemo1 = (MyValue, YourValue);

Ich habe übrigens gerade den Compilerschalter gefunden, der das von dir gewünschte Verhalten herstellt:

Delphi-Quelltext    ausgeblendet	markieren
1: {$SCOPEDENUMS ON}

Dann kannst du deine Deklaration benutzen und musst immer schreiben:

Delphi-Quelltext    ausgeblendet	markieren
1: 2: TTest1.FOO TTest2.FOO

Das ist leider auch das Problem bei einigen systemeigenen Prozeduren wie

Delete, eof ....

Leider ist - wahrscheinlich aus Lesbarkeitsgründen - das bei Prozeduren nicht umgesetzt worden. Wenn ich schon eine System.delete prozedur habe, wäre eine TTable.delete möglicherweise dann eine TTable.ttdelete gewesen oder ähnlich, dann hätte es keine Verwechslung gegeben und man müsste nicht System.delete schreiben.

Aber es ist ja nur ein kleines Problem. Zum Glück.

Tranx hat folgendes geschrieben :

Leider ist - wahrscheinlich aus Lesbarkeitsgründen - das bei Prozeduren nicht umgesetzt worden.

Es wurde z.B. bei den neuen Firemonkey-Units umgesetzt. Bei den alten konnte man es aus Kompatibilitätsgründen nicht machen. Und natürlich bleibt das Präfix dabei. Man muss nur zusätzlich den Typ davorschreiben. Beispiel:

Delphi-Quelltext    ausgeblendet	markieren
1: Canvas.Stroke.Kind := TBrushKind.bkSolid;

Ohne Präfix wäre es ja auch absolut unübersichtlich, eben z.B. auf Grund der von dir genannten Verwechslungsgefahr bei Klassenmethoden, die ja ebenfalls den Typ davor stehen haben.