[VB6] Public user defined type als parameter

[Verwijderd]

Ik probeer een door mezelf aangemaakt type te gebruiken als een parameter voor een sub van een eveneens door mezelf aangemaakte class.

Dit doe ik als volgt. Ik heb een public.bas waarin staat:

Visual Basic .NET:

Public Type Software
    myName As String
    myLocation As String
    myFile As String
End Type

Dan heb ik nog een clsEntry.cls waarin staat:

Visual Basic .NET:

Public Sub init(mySoft As Software)

     .... CODE .....

End Sub

Wanneer nu een instance van de klasse clsEntry als volgt aanroep:

Visual Basic .NET:

dim mySoft as Software
with mySoft
     .myName = "Test"
     .myLocation = "C:\"
     .myFile = "test.exe"
end with

dim myEntry as new clsEntry
myEntry.init mySoft

krijg ik de volgende error:

Only public user defined types defined in public object modules can be used as parameters or return types for public procedures of class modules or as fields of public user defined types.

Ik ben van mening dat ik aan al deze voorwaarden voldoe, maar nog blijf ik deze foutmelding krijgen. Weet iemand raad?

[ Voor 7% gewijzigd door Verwijderd op 15-08-2003 13:42 ]

[OZ-Gump]

Het verschil zit hem in de mening die jou is toegedaan en datgene wat er op je scherm staat. VB6 geeft namelijk aan dat je niet aan de wensen voldoet

Je hebt je type dan wel public gedeclareerd, maar staat hij ook in een 'public object module'? Da's de vraag, en daar zul je waarschijnlijk nee op moeten antwoorden. Uit een draadje op google groups haal ik het volgende:

A public object module is a class module whose "Instancing" attribute is set to something other than Private. If you are working on a Standard EXE project, the only Instancing value permitted by VB is Private, so this attribute is not visible in the properties window--in fact If you've never used an ActiveX project, you probably didn't even know the Instancing attribute exists.

Overigens blijkt hieruit dat je niet echt ver weg gezocht hebt Zoeken op google groups met als term re: VB "public object modules" had dit draadje als eerste result...

[ Voor 9% gewijzigd door OZ-Gump op 15-08-2003 13:25 ]

[Verwijderd]

Hoewel je hiermee misschien de vraag beantwoord hebt waarom VB de foutmelding geeft schep je tegelijkertijd ook weer een nieuwe vraag. Hoe maak ik dan een 'public object module'. Als ik het door jou aangeleverde draadje mag geloven dan kan je de class module attribute instancing niet aanpassen. Ik heb echter door eveneens op google te zoeken wel een oplossing gevonden voor het probleem: Friend Sub ipv Public Sub. Dit lijkt te werken, maar ik weet eigenlijk niet of er nog bijwerkingen aan verbonden zijn...

[OZ-Gump]

Maareh... als ik het goed begrijp is je probleem nu opgelost? Rest de vraag in hoeverre Friend van invloed is op de werking van je app... Mij lijkt het van niet. De help van VB6 zegt over Friend Declaraties het volgende:

Friends
In some circumstances, it is more convenient to grant member-level access to functions that are not members of a class or to all functions in a separate class. With the friend keyword, programmers can designate either the specific functions or the classes whose functions can access not only public members but also protected and private members.

Hier haal ik vervolgens uit dat het inderdaad jouw probleem oplost. En ik voorzie verder geen grote bijwerkingen...?

[Verwijderd]

Ik voorzie voor zo ver ook geen problemen in VB. Echter ik weet niet of je weleens C++ geprogrammeerd heb. Ik heb dat namelijk wel, maar daar is Friend echt een hele grote 'nono'. Namelijk een friend verpest eigenlijk het hele idee van een class. Ik denk echter omdat hier alleen de functie een friend is (wat in C++ standaard zo is) dat er geen problemen zullen optreden. Wat me niet helemaal duidelijk is echter is het verschil tussen een friend en een public. Beide zijn toegankelijk voor iedereen van buitenaf, maar de public geeft problemen en de friend niet?!? Lang leve de onduidelijkheid...

[farlane]

Verwijderd schreef op 15 augustus 2003 @ 14:14:
Namelijk een friend verpest eigenlijk het hele idee van een class.

Volgens mij is dat niet zo, classes die verschillende functionaliteit hebben, maar wel met elkaar verbonden zijn zou je heel goed friends kunnen maken, of een gemeenschappelijke friend geven.

Als voorbeeld geeft Stroustrup een functie die een object van het type Vector en een object van het type Matrix met elkaar vermenigvuldigt.

- Je kunt em geen member maken van beide klasses
- Je wilt niet de interne representatie van de objecten toegankelijk maken voor iedereen
- Je moet wel toegang hebben tot de die interne gegevens van beide objecten.

Dus een goede kandidaat voor een friend.

[Verwijderd]

Ik weet niet of ik precies snap wat je met je voorbeeld bedoelt, maar mijns inziens is het altijd zo dat een friend altijd op een naar mijn mening charmantere manier worden afhgehandeld namelijk met een functie die gewoon de gewenste data uit het object 'spuugt' naar de vragende functie toe, op die manier krijgt de vragende functie wat hij wil zonder dat hij direct met zijn tengels aan de interne representaties kan zitten.

[farlane]

Verwijderd schreef op 15 August 2003 @ 16:59:
Ik weet niet of ik precies snap wat je met je voorbeeld bedoelt, maar mijns inziens is het altijd zo dat een friend altijd op een naar mijn mening charmantere manier worden afhgehandeld namelijk met een functie die gewoon de gewenste data uit het object 'spuugt' naar de vragende functie toe, op die manier krijgt de vragende functie wat hij wil zonder dat hij direct met zijn tengels aan de interne representaties kan zitten.

[selfquote]
- Je wilt niet de interne representatie van de objecten toegankelijk maken voor iedereen
[/quote]

Dat doe je dus wel als je daarvoor access functies gaat maken, iedereen kan die aanroepen en zo krijg je nog een systeem dat afhankelijk is van de interne representatie.
Het friend maken van de vermenigvuldiging, maak alleen die functie afhankelijk.