[VB6] Functie ombouwen naar DLL

[RaZ]

Ik heb een functie geschreven die een gegeven variable ombouwd d.m.v diverse berekeningen.

Aangezien ik eigenlijk niet wil dat anderen er met de code vandoor gaan, wil ik er dus een DLL van maken.

ik stuur ten alle tijde een nummer naar de functie, en krijg ook weer een nummer terug. Maar als ik nu in VB6 een ActiveX DLL wil maken, en daar de source in ram, wilt deze toch niet werken.

Ik heb dus 1 class, met daarin een Sub Main() en een Public Function met daarin de berekening.

Maar als ik de DLL aanroep, met de naam van de functie met een nummer erachter, krijg ik als melding dat de routine van de functie niet betaat.

Kan niets vinden op google/got, maar een goeie how-to / tutorial m.b.t. het maken van DLL's in VB heb ik nog niet kunnen vinden.

[P_de_B]

Heb je als projettype "New ActiveX DLL" gekozen?

[RaZ]

P_de_B schreef op 15 september 2004 @ 21:31:
Heb je als projettype "New ActiveX DLL" gekozen?

Jup,

Dan komt VB zelf met een Class, daarin zet ik een sub & een function:

code:

Sub Main()

End Sub

Public Function MijnFunctie(nummertje as double)
..
End Function

In de function staat dus m'n code. sub main is leeg, want ik heb een sub main nodig schijnbaar (net als met een EXE file)

[ Voor 4% gewijzigd door RaZ op 15-09-2004 21:37 ]

[P_de_B]

Het creeren van het object gaat wel goed (Server.CreateObject)
Heb je misschien iets aan deze link?

[Lustucru]

Nog even uitgeprobeerd maar een sub main is echt niet nodig in een (vb6 active x) DLL. In de basis werkt het allemaal recht-toe-recht aan. Hoe roep je die functie aan?

[RaZ]

P_de_B schreef op 15 september 2004 @ 21:44:
Het creeren van het object gaat wel goed (Server.CreateObject)
Heb je misschien iets aan deze link?

Server.CreateObject heb ik niet echt nodig, ik wil de DLL kunnen aanroepen vanuit een VB6 applicatie.

Niesje schreef op 15 september 2004 @ 21:52:
Nog even uitgeprobeerd maar een sub main is echt niet nodig in een (vb6 active x) DLL. In de basis werkt het allemaal recht-toe-recht aan. Hoe roep je die functie aan?

Die sub main heb ik er al uitgegooit. Het testen doe ik doormiddel van mirc commando's aangezien deze ook DLL's kan aanroepen.

code:

//echo $dll(c:\raztools.dll,MijnFunctie,2563567)

Daar krijg ik dan terug: no such routine: MijnFunctie

[igmar]

RaZ schreef op 15 september 2004 @ 21:27:
ik stuur ten alle tijde een nummer naar de functie, en krijg ook weer een nummer terug. Maar als ik nu in VB6 een ActiveX DLL wil maken, en daar de source in ram, wilt deze toch niet werken.

Over het algemeen is het een slecht idee om classes te gebruiken. Verder dien je functies in een windows DLL expliciet aan te geven als dllexport, en dien je de juiste calling conventie te gebruiken.

Maar als ik de DLL aanroep, met de naam van de functie met een nummer erachter, krijg ik als melding dat de routine van de functie niet betaat.

Da's omdat C++ functienamen mangled.

[Lustucru]

RaZ schreef op 15 september 2004 @ 21:59:
Die sub main heb ik er al uitgegooit. Het testen doe ik doormiddel van mirc commando's aangezien deze ook DLL's kan aanroepen.

code:

//echo $dll(c:\raztools.dll,MijnFunctie,2563567)

Daar krijg ik dan terug: no such routine: MijnFunctie

Dat werkt idd niet. Een activex-dll stelt active-x componenten beschikbaar. In vb6 moet je dus eerst een referentie instellen en dan kun je je dll als volgt gebruiken:

code:

     Dim obj as  New [projectnaam].[classnaam]
     debug.print obj.mijnfunctie([parameter])
     set obj = nothing

[farlane]

igmar schreef op 15 september 2004 @ 22:21:

Over het algemeen is het een slecht idee om classes te gebruiken. Verder dien je functies in een windows DLL expliciet aan te geven als dllexport, en dien je de juiste calling conventie te gebruiken.

Da's omdat C++ functienamen mangled.

Je hebt wel gezien dat het hier om VB gaat ?

[Verwijderd]

Ik denk dat je eerst goed het onderscheid moet maken tussen DLL export functies en activeX (COM) componten. DLL export functies liggen nl. op een lager niveau als activex componeten.

Vanuit Visual Basic 6.0 kun je zelf geen dll functies aanbieden, dit kan bijvoorbeeld wel vanuit C/C++.

Door van je project een aciveX dll te maken kun je wel activeX componenten met de bijbehorende methoden aanbieden die vanuit andere programma's aangeroepen kunnen worden. Dit is wat je ook hebt gedaan en zoals het hoort.

Als ik het goed begrijp probeer je valuit MIRC een dll export functie aan te roepen. Dit kan dus helemaal niet omdat je VB pjoject helmaal geen dll functie exporteerd maar acitveX componenten.

Tenzij MIRC ook aan manier heeft om activeX componenten te creeren en daar mothoden op aan te roepen gaat dit je dus nooit lukken. Het enige andere alternatief is om vanuit C of C++ een DLL export functie te maken die vervolgens weer je VB activeX componentje aanroept dit is natuurlijk wel een beetje een overkill. Je kunt dan net zo goed de functionaliteit gelijk in C schrijven.


PS.

igmar schreef op 15 september 2004 @ 22:21:
[...]

Over het algemeen is het een slecht idee om classes te gebruiken. Verder dien je functies in een windows DLL expliciet aan te geven als dllexport, en dien je de juiste calling conventie te gebruiken.

[...]


Da's omdat C++ functienamen mangled.

Dit slaat natuurlijk nergens op, vanuit VB (6.0 dan) is de enige manier om functionaliteit naar buiten aan te bieden juist via classes. Hier is niets mis mee, het is juist veel netter dan DLL exports. Zoals gezegd kun je in VB je functie ook helemaal niet als DLL export markeren.