• Hi,

    Ich zerbreche mir gerade den Kopf ueber folgende Gehirnuebung:

    Ich glaube es kann einfach nicht funktionieren alle moeglichen enum Optionen mit get wieder zurueckzugeben, sodass ich den untenstehenden Code ausfuehren kann, richtig?

    Code
    MenuOptions myOption1 = myMenu.Options.option1;

    *** Make it idiot proof, and someone will build a better idiot. ***

  • Meinst du sowas?

  • Ah sorry schlecht gelesen - hab das glaub ich falsch verstanden sehe ich grade ...

    Das ist dann wirklich knifflig. IEnumerable aus dem ersten Post generisch machen - dann geht LINQ drauf. Oder:



    Sorry - war gerade laufen und hab wohl net sauber gelesen was du willst ;) Andere Möglichkeit als diese fällt mir nicht ein :confused:

    Einmal editiert, zuletzt von damike (21. Februar 2010 um 15:50)

  • Darf man fragen, warum du hier überhaupt eine enum verwendest? Wenn du die Menüelemente schon hardcoden willst, kannst du das mit Listen fast genauso einfach schreiben:

    Code
    public class Menu
    {
          private List<String> options=new List<String>{"option1","option2","option3"};
          [...]
    }


    Komplizierter:

    Code
    public class Menu
    {
          private List<Option> options=new List<Option>{new Option("option1"),new Option("option2"),new Option("option3")};
          [...]
    }


    Oder wenn du das ganze in einem statischen Repository haben willst, kannst du immer noch eine Enumeration verwenden, dann aber für die Menüs selber:

  • Danke fuer das Brainstorming.

    @Lists<> vs. Enums: Enums haben den eindeutigen Vorteil, dass Du die einzelnen Elemente deutlich netter ansprechen kannst und Du genau weisst, welche erlaubt sind, und welche nicht.

    @Warum ich mir darueber den Kopf zerbreche: Teilweise sicher aus sportlich-akademischen Ehrgeiz. ;) Ich moechte einfach wissen, ob es eine Moeglichkeit gibt eine (volle) Enum (nicht einzelne Elemente) als ("private") Parameter weiter zu reichen und als (public) Property in einer anderen Klasse zur Verfuegung zu stellen.

    Die Loesung mit Lists<> klaert das Problem fuer mich nicht wirklich. Da wuerde ich schon eher bei meiner derzeitigen Loesung bleiben, und die Enum direkt durch die Klasse die das SubMenu object definiert (und die Enum definiert) accessible machen. Das hat fuer mich den Schoenheitsfehler, dass ich dann so auf die Properties zugreifen muss:

    Anstatt des eleganteren Zugriffs ueber:

    Code
    MenuWrapper wrapper = new MenuWrapper();
    wrapper.SubMenu ...
    if (currentOption == wrapper.SubMenu.Options.option1) ...

    PS: Enums koennen uebrigens auch "dynamisch" = basierend auf Datenbankwerten sein, siehe hier.

    *** Make it idiot proof, and someone will build a better idiot. ***

  • Ja, wenn du es so machen willst, tu dir keinen Zwang an. Imho ist es aber voll am Konzept von Enumerations vorbei, siehe auch hier: http://msdn.microsoft.com/de-de/library/ms229058.aspx .
    Die "dynamischen" Enums von deinem Link her sind auch immer nur zu einem bestimmten Zeitpunkt generiert. Änderst du was an der Datenbank, musst du das Programm neu bauen.
    Wenn du noch immer unbedingt Enums verwenden willst, kannst du dir den Zugriff vielleicht mit Erweiterungsmethoden noch weiter verschönern. Dazu gibts in der MSDN-Library auch noch ein Enum-Beispiel.

    EDIT: Grad hab ich das abgeschickt, hab ich noch was gefunden, was dein ursprüngliches Problem so lösen könnte, wie du es haben willst: http://msdn.microsoft.com/de-de/library/cc138362.aspx (Ganz unten: "Verwenden der System.Enum-Methoden zur Ermittlung und Behandlung von Enumerationswerten")

  • Danke fuer die Links. Wrapper fuer die System.Enum methoden, bzw. eine generische Klasse fuer Enums/Enumhandling hab ich bereits.

    *** Make it idiot proof, and someone will build a better idiot. ***

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!