Ang. oprettelse: I eksemplet vises der hvordan man opretter en enum, vha. myEnumBuilder.
Ang. brug: Der vises dog ikke hvordan man "bruger den". Måske er det der problemet ligger. Du vil ikke kunne "bruge" din enum på sædvanlig vis, vha. den sædvanlige syntax, i stil med:
MyEnum e = MyEnum.Monday; if(e == MyEnum.Monday) Console.WriteLine("Its monday");
Da compileren ikke kender din enum compile-time. Du skal altså finde din enum og dens elementer programatisk.
Spørgsmålet er om du vinder noget ved at oprette din enum dynamisk, hvis det eneste formål er at du skal teste på værdien af en "enum", ell. lign. Jeg kender ikke dit konkrete problem, men et skud fra hoften ville nok være at findes en løsning der var mere enkel (i stil med at gemme "enum" væriderne i en liste og slå dem op når de skal bruges)...
har læst på nettet om een der brugte (bl.a.) dynamisk enum oprettelse. Han gemte dog den emittede kode i en dll. Denne .dll blev der så refereret til i en solution. På denne måde kunne man kontrollere hvilke enums, der var lovlige i koden. Så man havde en slags "regl"-database, som dannede grundlag for hvilke værdier (enums) der kunne bruges i deres kode. Men i det tilfælde var den dynamiske enum-oprettelse et pre-step til kompileringen af det egentlige projekt, og på den måde vidste compileren hvilke enums der var tilgængelige (og kunne altså derfor komme med fejl compile-time).
Mit problem er at jeg skal lave en webpart til sharepoint hvor en property på webparten skal sættes udfra en dropdown. Problemet med webparts er bare hvis jeg skal lave en dropdown, skal det gøres udfra enums. Og det er her det ikke helt hænger sammen, jeg kender nemlig ikke værdierne compile time...
jeg har ingen erfaring med webparts. Min umidlbare indskydelse er nok:
** det ser ud til at din drop down angives som en property på din klasse (en property der returnerer en enum-type). Typen af denne enum skal være kendt for at kunne kompilere klassen, og da du ikke kender typen af din enum på kompilerings tidspunktet (men først run-time), kan problemet ikke løses på denne måde.
hvofor er den mon sådan: (aner det ikke, men kan da gætte - du har sikkert bedre forstand på det end mig). Jeg går ud fra at der er en mening med at sharepoint er designet på denne måde (at den bruger en enum). Som jeg forstår dig, ønsker du at have en webpart der har en property der kan ændre sine mulige værdier run-time. Hvis den property f.eks. er en farve: enum Color { Blue, Red }
...og jeg går ind i webpartens property og vælger f.eks. Blue. Men lige efter jeg har valgt den ændrer webpartens property til:
enum Color { Yellow, Red }
...og blue er lige pludselig ikke gyldig længere - det ville vel være et problem? at man har en forventning om at en property er sat, men øjeblikket efter er property'en ugyldig.
men som sagt, så aner jeg ikke noget om webparts og sharepoint - så mine "gæt" kan meget vel være skudt forbi...
hvis du derimod ønsker at have en mulighed for at "opdatere" din webpart automatisk, kan det måske godt lade sig gøre!?: 1) lav et tool: "UpdateWebpartWithNewEnum". Toolet genererer en CustomPropertyValues.dll. Denne .dll indeholder din enum og bruges af din webpart. 2) dit webpart-projekt har en reference til din CustomPropertyValues.dll og finder typen på din enum-property i denne dll. 3) når din webpart skal opdateres automatisk, køres "UpdateWebpartWithNewEnum" toolet, og din webpart rekompileres.
Jah... jeg finder nok på noget :-) tak for din indsats...
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.