HDSoftware Skrevet 12. februar 2007 Skrevet 12. februar 2007 (endret) Heisan VB guruer (eller Visual studio om du vil) Jeg har lagt merke til et par ting i Microsoft OOP verden og det er måten man helt uten videre kan bruke metoder i andre klasser direkte. Tenker spesiellt på .Tostring metoden. Det virker som om denne metoden er tilgjengelig uansett klasse og objekt - ja selv i mine klasser der ToString på ingen måte er deklarert, kan jeg bruke den. Noen som kan fortelle meg hvordan dette gjøres? Eller er dette bare en del av VB? For jeg kunne virkelig tenke meg å lage mine egne varianter her. mvh Ole Endret 14. februar 2007 av HDSoftware
tZar Skrevet 12. februar 2007 Skrevet 12. februar 2007 Denne posten burde vel helst vært under .net underforumet hvis jeg ikke tar feil? Det er vel et vb.net spørsmål?
j000rn Skrevet 12. februar 2007 Skrevet 12. februar 2007 Alle klasser arver av System.Object. System.Object inneholder .ToString(). Du kan override den i din klasse.
GeirGrusom Skrevet 12. februar 2007 Skrevet 12. februar 2007 Dette fungerer som et tre, alle klasser som inheriter fra object (absolutt alle klasser) har en ToString() funksjon, en GetHash() funksjon og GetType(). Disse vil alltid være med klassen din, i motsetning til GetType() er ToString og GetHash() virtuelle funksjoner, de kan byttes ut i din nye klasse, hvis du ikke sier noe spesielt, hvil den bruke ToString() funksjonen fra forrige gang den var deklarert i treet (hvis du lager Class MyClass så vil den automatisk inherite fra Object, og det er her den får ToString() fra)
HDSoftware Skrevet 12. februar 2007 Forfatter Skrevet 12. februar 2007 Denne posten burde vel helst vært under .net underforumet hvis jeg ikke tar feil? Det er vel et vb.net spørsmål? 7924687[/snapback] På ingen måte (tror jeg) Det er nermest et spørsmål om OOP og har vel ingenting med .NET å gjøre. Det er selvsagt mulig jeg tar litt feil her hvis det er slik at det er .NET engine som tar seg av dette, men i utgangspunktet er det et generellt OOP spørsmål. Ole
HDSoftware Skrevet 12. februar 2007 Forfatter Skrevet 12. februar 2007 Jorn79 og GeirGrusom: Skjønner. Det er med andre ord en automatisk prototype dette her, som faktisk gjøres på compiler nivå og ikke byCode. Da hadde sikkert han som kommenterte det litt rett med tanke på at dette er en .NET sak. Jeg går ut ifra at jeg kan gjøre "nesten" det samme med interface? Jeg har gjort mye interfacing i Clarion, men ikke i VB (enda). Må derfor spørre: I Clarion er det slik at et Interface kunn er et tillegs prototype av metoder som er en "felles" platform til klassene. F.eks: EttInterface Interface Init PROCEDURE Kill PROCEDURE END Når jeg skal bruke dette i en klasse gjør jeg slik: EnKlasse CLASS,INTERFACE(EttInterface) EttInterface.Init PROCEDURE EttInterface.Kill PROCEDURE END Og videre kan jeg selvsagt legge egen kode bak disse "interface" metodene. Med andre ord er det ikke noe kode bak interface metodene fra før. Ei heller kan et interface ha properties. BLir det på samme måten i VB tro? Greia er at bruk av interface gjør at forskjellige klasser med enkelhet kan komunisere med hverandre uten at de egentlig vet om hverandre. Jeg pleier gjøre dette gjennom en kø av objekter, så å si en kø med referanser til komponenter, der objektet i seg selv kaller ut av seg selv og inn i "ukjente" objekter gjennom interfacet. Ganske fancy teknikk egentlig. Det var vel egentlig noe slikt jeg tenkte denne ToString greia var bygget opp rundt. Ole
GeirGrusom Skrevet 12. februar 2007 Skrevet 12. februar 2007 (endret) Interface fungerer helt likt i .NET som det gjør i Clarion. Interfaces garanterer at en klasse implementerer visse funksjoner og egenskaper, uten å inneholde noe kode. En klasse kan inherite fra kun én annen klasse, men så mange interfaces man vil. Alle funksjoner or egenskaper vil følge med arve-treet, også interfaces. I .NET blir alle klasser basert på Object, enten du liker det eller ikke, derfor er et interface helt unødvendig, siden alle klasser implementerer disse funksjonene uansett. Endret 12. februar 2007 av GeirGrusom
HDSoftware Skrevet 12. februar 2007 Forfatter Skrevet 12. februar 2007 I .NET blir alle klasser basert på Object, enten du liker det eller ikke, derfor er et interface helt unødvendig, siden alle klasser implementerer disse funksjonene uansett. 7928181[/snapback] Dette var litt uklart for meg. Du sier alle klassert er basert på objekter?!?! Virker på meg motsatt av all logikk da objecter normalt instanseres fra en klasse. Kan du utdype litt nærmere? mvh Ole
j000rn Skrevet 12. februar 2007 Skrevet 12. februar 2007 Dette var litt uklart for meg. Du sier alle klassert er basert på objekter?!?! Virker på meg motsatt av all logikk da objecter normalt instanseres fra en klasse. Kan du utdype litt nærmere? 7930491[/snapback] System.Object (ikke "objekter") er en klasse. Alle klasser arver av denne
HDSoftware Skrevet 13. februar 2007 Forfatter Skrevet 13. februar 2007 Dette var litt uklart for meg. Du sier alle klassert er basert på objekter?!?! Virker på meg motsatt av all logikk da objecter normalt instanseres fra en klasse. Kan du utdype litt nærmere? 7930491[/snapback] System.Object (ikke "objekter") er en klasse. Alle klasser arver av denne 7930716[/snapback] Ahh, da skjønner jeg, men hvorfor gjør dette et interface unødvendig? Hvis jeg ønsker å standardisere mine klasser så er vel et interface den eneste veien, er det ikke? Eller mener du å si at alle objekter i andre grener av dette treet også er tilgjengelig fra mine klasser? I så fall betyr vel dette at alle objekter er globalt definert. Og i så fall, hvordan er det med instanser som går på andre tråder? Jeg er vant til at man kan ha en peker i en prosedyre som er en referanse til et object, f.eks. i en helt annen tråd. Dermed kan man utføre metodene som dette objektet har. Jeg har litt vondt for å forstå trådhåndteringen i VB, men det blir vel klarere etter hvert tenker jeg :-D Ole
GeirGrusom Skrevet 13. februar 2007 Skrevet 13. februar 2007 Interfaces er ikke unødvendig i det hele tatt, poenget er egentlig bare at Object ikke er et interface, siden alle klasser arver denne, så vil alle klasser ha disse egenskapene uansett - dette gjelder object, siden det er grunnklassen. Jeg tror ikke .NET er noe annerledes en i Clarion på dette området. Når det gjelder tråder, så finnes det to begrensinger: System.Windows.Forms objekter hvor du skal kalle metoder på tvers av tråder, må du bruke Invoke funksjonen. Når det gjelder alle andre klasser, må variabler som brukes på tvers av tråder deklareres volatile (i C#, jeg vet ikke hva dette heter i Visual Basic) grunnen til dette, er at variabler som ligger på stack(hver sin stack på hver thread), vil bli lagret i cachen til prosessoren, dette gjør at verdier ikke vil bli ordentlig oppdatert for hver tråd(den gamle verdien, eller null vil ligge der) volatile hindrer dette. Det tror jeg er det eneste, utenom det er cross-thread call ganske simpelt.
j000rn Skrevet 13. februar 2007 Skrevet 13. februar 2007 Når det gjelder tråder, så finnes det to begrensinger:System.Windows.Forms objekter hvor du skal kalle metoder på tvers av tråder, må du bruke Invoke funksjonen. 7934962[/snapback] Eller man kan være sløv og bare sette: Control.CheckForIllegalCrossThreadCalls = false;
GeirGrusom Skrevet 13. februar 2007 Skrevet 13. februar 2007 Din late slask! Således trodde jeg da ikke om dem!
HDSoftware Skrevet 14. februar 2007 Forfatter Skrevet 14. februar 2007 Din late slask!Således trodde jeg da ikke om dem! 7936850[/snapback] Takker folkens Masse nyttig informasjon her. Har prøvd meg litt på Raiseevent og ser at INVOKE brukes der. Må studere invoke litt mer, men ser bruksmåten. I Clarion måtte jeg gjøre det litt annerledes for å få tak i metoder i andre tråder. Den ene måten jeg kunne bruke var enkelt og greit å overføre adressen til objektet i det jeg startet en ny tråd. I Clarion kan man nemlig starte en tråd med tre parametere og disse måtte være string. Gjorde noe slik: Hovedproc PROCEDURE LOC:NewThread LONG EttObjekt &KlasseDef CODE EttObject &= new(KlasseDef) EttObjekt.Verdi1 = 10 LOC:NewThread = Start(Prosedyrenavn, Format(Address(EttObjekt,@P##########P)) Da vil prosedyren som starter tråden ha tråd ID til den nye tråden Den startede prossedyren vil da se noe slik ut: Prosedyrenavn PROCEDURE(pPassedAddress STRING) ObjektRef &Klassedef CODE ObjektRef &= int(pPassedAddress) Message(ObjektRef.Verdi1) ! Vil vise verdien 10 ObjektRef.Verdi1 = 20 Siste linje vil sette ny verdi for Verdi1 og den er dermed automatisk tilgjengelig for hovedprosedyren. Går vel ut ifra at dette gjøres på noe av den samme måten i VB. Det som kan være problemet med denne teknikken er jo at to eller flere tråder kan finne på å skrive til verdier i samme objekt samtidig og skape kaos, men dette fikses gjerne med IMUTEX eller Critical Section. Vet ikke om VB har noe slikt, men det går jeg vel ut ifra Ole
GeirGrusom Skrevet 14. februar 2007 Skrevet 14. februar 2007 Det stemmer. se på Mutex klassen. System.Threading.Thread er klassen for å lagwe nye threads
HDSoftware Skrevet 14. februar 2007 Forfatter Skrevet 14. februar 2007 Det stemmer.se på Mutex klassen. System.Threading.Thread er klassen for å lagwe nye threads 7939734[/snapback] Takker Anser problemstillingen som løst. Er det et sted jeg kan "stenge" tråden? Ole
j000rn Skrevet 14. februar 2007 Skrevet 14. februar 2007 Det stemmer.se på Mutex klassen. System.Threading.Thread er klassen for å lagwe nye threads 7939734[/snapback] Takker Anser problemstillingen som løst. Er det et sted jeg kan "stenge" tråden? Ole 7940390[/snapback] Hvorfor skal du stenge tråden? Det kan hende at andre har kommentarer også... Vanlig er heller å legge til "LØST" eller lignende først i emnetittelen.
HDSoftware Skrevet 14. februar 2007 Forfatter Skrevet 14. februar 2007 Hvorfor skal du stenge tråden? Det kan hende at andre har kommentarer også... Vanlig er heller å legge til "LØST" eller lignende først i emnetittelen. 7940452[/snapback] Du - det var vel egentlig det jeg ville ;-) Stenging av tråd overlater jeg til moderator gutta. Tenkte kansje det var en avkryssing ett eller annet sted der tråden ble merket som LØST eller noe slikt. Fikk dermed svar på spørsmålet ;-) Ole
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå