Vælge dll fil i switch case

Bump.... (Gør lige det her for at se hvor pokker mit spørgsmål blev af. Den er ikke kommet i listen over spørgsmål, kan kun finde den i listen over nyeste spørgsmål :-S)

Hej zeroaim,

Det lyder som om din variabel der registrerer brugerens valg via "switch" udtrykket bliver erklæret inde i selve "case" udtrykket. Prøv se mine eksempler nedenfor:



1) Dette kan ikke kompileres da strFile ikke kan bruges efter switch.


int switchArgument = 0;

switch (switchArgument)
{
    case 0:
                //Erklærer strFile in i switch
        string strFile = "File01";
        break;
    case 1:
        strFile = "File02";
        break;
    default:
        strFile = "File03";
        break;
}

//FEJL, for strFile er erklæret inde scopet af switch
System.Console.WriteLine(strFile); 


Så hvis du i stedet erklærer strFile-variablen før switch-udtrykket, kan du fint benytte den bagefter og checke for brugerens valg. Altså:


2) Dette kompilerer og køres fint.


int switchArgument = 0;

//Erklærer string file inden switch
string strFile = "";

switch (switchArgument)
{
    case 0:
        strFile = "File01";
        break;
    case 1:
        strFile = "File02";
        break;
    default:
        strFile = "File03";
        break;
}

System.Console.WriteLine(strFile); 


Håber du kan se problemstillingen fra mit eksempel og rette det i dit! :)


Mvh,

- Snap

Hej Snap

Ja det er lige netop mit problem. Men da de ikke bare er en simpel type (string) jeg skal ha' erklæret, men en instans af en klasse fra et namespace, hvordan skal jeg så erklære den før min switc?

Eks

using RemoteControl_1
using RemoteControl_2
using RemoteControl_3

...

switch(RemoteNumber)
case "1"
RemoteControl_1.Remote MyRemote = RemoteControl_1.Remote();

case 2 med RemoteControl_2.... osv osv

De tre forskellige klasser, implementerer de samme interface eller nedarver fra samme klasse, for så kan du gøre sådan her:

IRemoteControl remote;

switch (remoteNumber)
{
  case 1:
  remote = RemoteControl_1.Remote();
  break;
  case 2:
  remote = RemoteControl_2.Remote();
  break;
}

Ellers må du gemme dem i Object og gøre sådan:

Object tm = null;

switch (switchArgument)
{
    case 0:
        tm = new RemoteC1();
        break;
    case 1:
        tm = new RemoteC2();
        break;
    default:
        tm = new RemoteC1();
        break;
}

System.Console.WriteLine(tm.ToString());

Men som hmortensen siger, må de næsten nedarve samme klasse eller interface..


- Snap

hvis det er forskellige object typer kan det løses ved at lave en 'object' variabel og så selv holde styr på hvilken type det er.

object o;
int objecttype;

switch(RemoteNumber)
case "1"
  o = RemoteControl_1.Remote();

case 2 med RemoteControl_2.... osv osv

sorry havde ikke lige fået opdateret

Hmmm,,, jeg kan ikke få nogle af jeres (helt sikkert rigtige) svar til at virke.

Jeg roder lige lidt med det, men jeg skal jo nok kigge på at lade dem nedarve fra samme klasse/interface, men jeg har bare aldrig gjort det før, så jeg har nok lige lidt læsning inden jeg kan vurdere om det er løsningen.

Ud fra navnene at dømme, har de 3 klasser lidt ala samme funktionalitet, eller i hvert fald nogle fællestræk, så det burde ikke være umuligt at bygge et interface på.

Nej det er det garanteret heller ikke,,, men jeg kan bare ikke lige se det :-(

Prøver lige med lidt kode.  Her er en remotecontrol til media player:

namespace WMRemoteControl
{     
    public class Remote
    {
        [DllImport("User32.dll")]
        public static extern Int32 SendMessage(Int32 hWnd, int msn, int wParam, int lParam);

        private const int WM_COMMAND = 0x111;

        public void PlayPause(Int32 MyHandle)
        {
            SendMessage(MyHandle, WM_COMMAND, 0x00004978, 0x00000000);
        }

        public void Stop(Int32 MyHandle)
        {
            SendMessage(MyHandle, WM_COMMAND, 0x00004979, 0x00000000);
        }

        public void Next(Int32 MyHandle)
        {
            SendMessage(MyHandle, WM_COMMAND, 0x0000497B, 0x00000000);
        }

        public void Previous(Int32 MyHandle)
        {
            SendMessage(MyHandle, WM_COMMAND, 0x0000497A, 0x00000000);
        }

        public void Volume(Int32 MyHandle, string Vol)
        {
            switch(Vol.ToUpper())
            {
                case "UP":
                    SendMessage(MyHandle, WM_COMMAND, 0x0000497F, 0x00000000);
                    break;
                case "DOWN":
                    SendMessage(MyHandle, WM_COMMAND, 0x00004980, 0x00000000);
                    break;
                case "MUTE":
                    SendMessage(MyHandle, WM_COMMAND, 0x00004981, 0x00000000);
                    break;
                default:
                    break;
            }
        }

        public void FullScreen(Int32 MyHandle)
        {
            SendMessage(MyHandle, WM_COMMAND, 0x0000495E, 0x00000000);
        }
    }
}

Problemet er (for mig at se) at der kun er metode kaldene der vil være ens for en remotecontrol til eks. bsplayer.

WM_COMMAND vil ikke være ens. (Det er så til at fikse selvfølgelig)

Men PlayPause() vil skulle sende 3 messages for at få BSplayer til at Play eller Pause :-S

Skal jeg så lave en Superklasse eller???

Altså det jeg ligesom synes var smart ved den her måde er, at når alt kode alligevel skal skrives om hver gang, så bare lave det som hver sin assembly, for så kan min kammerat bare skrive en til eks. BSPlayer som jeg bare kan adde i mit projekt. Altså han kan skrive den uden adgang til in superklasse.

Men det kan godt være hele strukturen i projektet lige skal revurderes. Det er heldigvis bare for "sjov" jeg laver den, så der er tid nok :-)

Ok, alle tre klasser har metoderne "PlayPause, Stop, Next, Previous, volume og Fullscreen"?

Hvis ja, så laver du et interface.

public interface IRemote
{
  void PlayPuse(Int32 Handle);
  osv..
}

Det fortæller at klasser som implementerer interfacet SKAL have de metoder der, ellers kan du ikke compile. Endvidere kan du så caste din klasse til IRemote, som vist i tidligere indlæg.

Ja alle klasser skal ha' de metoder (+ lidt løse til de forskellige), så jeg hopper da på vognen og gør som jeg "får besked på" ;-)

Det bliver ændret til et interface. Det kommer lige til at tage lidt tid, men jeg vender tilbage.

Det er ny rart at man kan komme her på eksperten og få at vide hvad man skal gøre... Så slipper man jo for at tænke selv :-D

Be right back

Mvh Henrik

Husk, at hvis du bruger et interface, og caster dit object, til den type, kan du ikke kalde metoder og egenskaber som ikke er forskrevet i interfacet. Du kan selvfølgelig have private metoder som bliver kaldt fra de andre metoder af.

Og så ville jeg nok lave din dllimport private, da den jo ikke skal kunne kaldes direkte uden fra klassen.

Btw, lav dit interface i sin egen assembly som du så refererrer til fra dine tre andre assemblies.

Det vil altså sige, at hvis BSPlayer har en funktion som ikke understøttes i media player, så skal denne metode dog være tilstede i WMRemoteControl selvom den ikke kan bruges til noget?

btw er switch forøvrigt så meget langsommere eller mere resurce krævende at jeg bør bruge if/else i stedet? Bare et hurtigt spørgsmål, da jeg ved det kun anbefales at bruge switch når man har mange statemnts at løbe igennem... Jeg kan bare så godt lide switch og den måde den står på i koden :-D

Tror ikke der er den store forskel. Jeg ville bruge en switch her.

Hvis en afspiller ikke har den pågældende funtion, kan du smide en "not implemented" exception, som du så fanger i din gui.

Nice :-D

Jeg takker mange gange for den store hjælp indtil videre.

Jeg vender tilbage i aften, når jeg får tid til at lure lidt mere på det :-)

Hej

Jeg får desværre ikke lige tid at lave det her færdigt i den her uge alligevel :(, men jeg nåede da så langt den aften, at jeg praktisk talt har skrevet det hele om :-)

Jeg takker mange gange for hjælpen, men han der fik mig på det spor der har givet mig retningen er nok --- hmortensen.

Så hmortensen smid et svar så lukker jeg den her.

Mvh. Henrik

Det var så lidt.

Du kan jo bare skrive når du kigger på det igen, hvis det volder problemer.

Super, det gør jeg.

Lukker her