UcerControls og NameSpaces

Næ, jeg kan ikke rigtigt følge dig - hvad er det for noget kommunikation det skal være mellem dine UserControls og din form?

Jeg forstår ikke helt din beskrivelse af hvad du har lavet - "hvis UC'en skal kommunikere med HovedFormen benytter jeg events...og dvs. jeg hægter UC'ens eventHandeler op direkte på på UC'ens event..." ?

Normalt implementerer man nogle events på UserControl'en som formen hooker sig på i forbindelse med at den bliver initialiseret - misforstår jeg noget?

okey...jeg prøver igen...:)

Ja, normal implementere man events i UC som formen fanger...men hvad nu, når UC'en også skal fange events fra formen?

hmm - det lyder som en ret høj kobling som man jo helst skal undgå... jeg tror at jeg ville implementere nogle metoder på UserControllen - f.eks. i et interface eller lignende - og så give formen ansvar for at kalde...altså bruge "push" i stedet for "pull".

Hvorfor er koblingen højere den ene vej end den anden vej? Er det virkelig så skidt at gøre det? Kan ikke se at koblingen bliver mindre af at implementere metoder i UC'en og kalde dem direkte eller igennem interfaces...eller nu er det et stykke tid siden jeg har rodet med interfaces, men du mener at UC'en skal implementere interfacet og formen kalde/bruge metoderne i interfavet...så søger interfacet selv for resten/kalde den/de rigtige metoder, i UC'en/de klasser, som nu engang implementerer interfacet...er det ikke sådan det fungere...?

Koblingen bliver højere fordi formen skal "kende til" usercontrollen _og_ usercontrollen skal "kende til" den form den ligger på - ved at lade usercontrollen implementere nogle metoder så er der _kun_ formen der behøver at kende noget til usercontrollen. Det er go' latin at minimere koblingen :)

Det behøver ikke at være et decideret interface - det kan bare være almindelige public metoder...

1. øøhm...altså det som tidligere skrev var ok/det man normalt gør, at at implementere noget events i UC'en og så hægte formen op på dem...men der skal formen jo også kende/vide at eventen findes i Uc'en...det er jo det samme det anden ved...selvfølgelig omvendt...?

2. Ved metode kald til UC'en skal formen da ligeledes kende til metoden...hvad er forskellen så på events og metoder?

3. Jeg kan godt at se koblingen bliver mindre ved brug af interfaces...idet formen "viden" ikke går længere end ti linterfacets metoder, som så tager over...hvis jeg altså har fået det korrekt...det er sådan det virker, som jeg beskev ik'?

Prøv at læse dette link igennem, det skulle gerne give dig nogen svar:
http://openmymind.net/communication/index.html

;o)

ad 1.: Ja, formen skal kende til de events og metoder som UC'en udstiller men det er jo trods alt kun nødvendigt for formen at kende UC'en - UC'en skal ikke kende til den form der bruger den... hvis man f.eks. har lyst til at genbruge UC'en på en anden form skal den jo ligne den første ellers virker UC'en jo ikke.

ad 2.: Forskellen mellem events og metoder er nok primært det man bruger dem til - events bruger man til at fortælle at der er sket noget som dem der lytter på eventet skal være opmærksomme på - mange gange hentes der så noget data fra den der rejste eventet (pull)... Normalt sender man relevant data med ved kald af metoder (push)

Den anden forskel mellem events og metoder er at man ved at bruge events får en afkobling mellem dem der gerne vil kaldes i diverse situationer - den der smider eventet behøver ikke at vide noget om hvem eller hvor manger der lytter - det bliver den nødt til ved brug af metoder.

ad 3.: Jo, interfaces virker ved at UC'en implementerer et bestemt interface, hvilket jo bare betyder at den udstiller et bestemt sæt metoder - ved at bruge et interface afkobler man definitionen af disse metoder med den klasse der rent faktisk implementerer dem...

1. Jeg forstår og er enign i alt hvad du siger...men skal lige have bekræftet noget :)
Tror lige der gik et lys op for mig...? Forskellen på om form eller UC fyrer eventen eller fanger eventen via EventHandler...er jo...den korrekte måde: Så findes eventen altid(i UC) og så kan formen bruge den eller ej....men det er derimod ikke go' stil at UC'en SKAL hooker sig op på en event, som formen så er "tvunget" til at implemnetere inden da... ja det er noget skidt, først og fremmest hvordan UC'en skal få fat i en ref. til formen...og ja man vil løbe ind i problemet hvér gang man vil genbruge kontrollen...og ja, formen/ref. skal være af samme type...det er såN det hænger sammen, ik?-)

2. BTW...har tænkt meget over det med interfaces eller direkte metodekald...normalt vil det være pænest med brug af interfaces ik? Men nu hvor det ér en UC så kan man jo ikke undgå at have en instans til rådighed i formen (hvis man vel og mærke har valgt at bruge den UC'en!) og derfor synes jeg det virker mest naturligt, at man benytter direkte metodeklad...hva' siger du?

ad 1.: Jo, lige præcis :)

ad 2.: Jo, det er altid en afvejelse af om det at implementere et interface gi'r noget eller om det bare er et ekstra "overhead" - jeg implementerer heller ikke selv interfaces på kontroller :)

Super! Ja og hvis situationen opstod, hvor der reelt var smart et bruge interfaces, ville jeg nok vælge at benytte evets i stedet for:) Med mindre, at selvfølgelig skla fungere, som en "kontrakt" imellem arkitekt og programmør, så er det selvfølgelig en anden sag...er også andre smart ting man kan bruge interfaces til...eller? ja, okey...man kan skjule funktionalitet ved at lave eksplicitte interfaces, men det var nu ikke lige det jeg tænkte på...:)

Læg du blot et svar næste gang, så får du dine velfortjente points!

Mange tak for hjælpen

Mvh. PabloPablo

1 stk. svar :)