Synligheten av deklarasjoner i forskjellige SCOPE

[HDSoftware]

Hei folkens

 

Gitt følgende:

Public Class TestKlasse
.
.
 Public MustOverride Function GetNumberOfRecords as Integer
.
.
End Class

Så i et program som bruker klassen:

Public Class TestWindow
 Private TestObjekt as new LocTestClass
 Public ThisList as List(of String)
.
.
.

Private Class LocTestClass
 Inherits TestKlasse
 Public Overrides Function GetNumberOfRecords() as Integer
   Return ThisList.Count()    <--Feiler
 End Function
End Class

Jeg får melding fra IDE at objektet ikke er shared og det stemmer jo for såvidt. Er det en enkell måte å få den lokale klassen til å kunne bruke samme scope som den klassen som instanserer den? Jeg kan selvsagt legge inn en referanse, men jeg hadde håpet at dette var automatisk på en måte.

I Clarion er jeg vant til følgende:

<Scope1>  Ser DefA og DefB
 DefA, DefB
       <Scope2>  Ser DefA, DefB, DefC og DefD
         DefC, DefD
       <Scope3>  Ser DefA, DefB, DefE og DefF, men ikke DefC og DefD
         DefE, DefF
                  <Scope4>  Ser DefA, DefB, DefE, DefF og DefG
                    DefG

Noen som vet noe om dette?

[HDSoftware]

Virkelig ingen som har hatt behov for dette før?

[GeirGrusom]

Private: Kun for den ene deklarasjonen.

Internal: Kun for dette prosjektet

Protected: Deklerasjonen, pluss underklasser

Protected Internal: Deklerasjonen, pluss underklasser i dette prosjektet

Public:Alle

 

Dessuten kan du bruke interfaces for å åpnne samme resultat.

[HDSoftware]

Spørs om ikke du missforstod. Her er et eksempel:

Public Class MainClass
   Public DefA As Integer
   Private Class Test
       Public Sub Testing()
           DefA = 1         '< ------Feiler
       End Sub

   End Class
End Class

Og dette feiler uansett hvordan du definerer DefA

Endret 24. april 2007 av HDSoftware

[aadnk]

Jeg tror du blir nødt til å gi en referanse til MainClass når du instantierer Test, evt. benytte globale variabler.

[HDSoftware]

Ok. Så det betyr at variabler ikke er kjent i underliggende nivåer med andre ord. Merkelig ugron, siden man på mange måter kan se på den omringende klassen som en modul til den underliggende klassen.

Uanset - Synd, da dette bare skaper mer arbeid.