[VB] Dll Debuggen

[PoweRoy]

zit hier met een vaag probleempje dat volgens google op te lossen is (maar dus neit werkt)

ik heb:
een project die bij make een dll maakt
een project die de dll gebruikt

Nu lees ik bij sommige sites dat je de dll kan debuggen door bij het dll-project, de optie wait for components to be created moet aanvinken. Ergens een breakpoint zetten waar hij komt en dan run.

Nu het andere project openen en dan run. Nu zou hij als je van dit project naar het dll-project springt, kunnen debuggen.
Dit krijg ik hier niet aan de praat. Naar mijn idee gebruikt het exe-project de dll, ipv die in het ?geheugen? geladen is.

Zijn er andere opties waar ik naar moet kijken

[Lorn]

De manier die je beschrijft heb ik zelf nooit gebruikt. Wat je kunt ook beide projecten in dezelfde instantie van VB6 openen. Je moet zorgen dat het project dat de exe bevat als startup staat ingesteld. Vervolgens kun je gewoon breakpoints zetten in de code van je DLL en zal VB keurig stoppen zodra de code wordt aangeroepen.

[PoweRoy]

je kan een 2e project toch niet in dezelfde instance open in VB6 als ik 1 project geopend heb en wil de 2e openen, sluit hij eerst de eerste af.

Die optie die jij beschrijft, bij debuggen optie, de exe ook opstarten geeft helaas ook niet het gewenste resultaat.

ook ff geprobeerd de dll met regsvr32 /u te unregisteren, dit werkte maar kan nog steeds niet debuggen

[Gerco]

Ik heb deze optie weleens gebruik en precies op de manier waarop je die beschreef:

- Eerst alle instanties van de gecompileerde dll unregisteren
- Register opschonen (zoeken naar ProgID van je DLL en alles weggooien)
- DLL opstarten in "Wait for components to be created" mode
- Gebruikend prog opstarten binnen VB (eerst opnieuw reference aanklikken, want de oude GUID is weg)

Op deze manier werkt het overigens niet om de gecompileerde app te starten terwijl je alleen de dll debugt. Je gooit namelijk alles van de dll eerst weg, inclusief zijn GUID. Met een binary compatible component moet het overigens wel kunnen, maar je moet er dan heel goed voor zorgen dat die component NIET geregged is.

Het makkelijkste is om beide projecten in 1 project group te zetten (Met "add project" in het menu) en dan de reference op de applicatie opnieuw zetten (naar het dll project). Dat werkt in mijn ervaring het beste.

Conclusie: COM zuigt.

[jan-marten]

Wat Lorn bedoelt is een Visual Basic group aanmaken.
Heel simpel, je maakt een bestandje.vbg en daar zet je de volgende 3 regels in:

code:

VBGROUP 5.0
Project=DLLproject.vbp
StartupProject=TestProject.vbp

Deze procedure zal vast ook in VB kunnen maar dan zou je even moeten zoeken.

[PoweRoy]

jan-marten schreef op woensdag 12 april 2006 @ 13:11:
Wat Lorn bedoelt is een Visual Basic group aanmaken.
Heel simpel, je maakt een bestandje.vbg en daar zet je de volgende 3 regels in:

code:

VBGROUP 5.0
Project=DLLproject.vbp
StartupProject=TestProject.vbp

Deze procedure zal vast ook in VB kunnen maar dan zou je even moeten zoeken.

gedaan maar werkt dus helaas niet, hij springt van de if naar de else. Maar waarom gaat hij die functie niet in



EDIT
en de breakpoint in de service_item_line_tabel werkt ook niet

[ Voor 6% gewijzigd door PoweRoy op 12-04-2006 13:47 ]

[Gerco]

PoweRoy schreef op woensdag 12 april 2006 @ 13:45:
gedaan maar werkt dus helaas niet, hij springt van de if naar de else. Maar waarom gaat hij die functie niet in

Heb je de reference naar de DLL ook opnieuw ingesteld in de reference dialog voor de aanroepende applicatie ? Er zullen nu waarschijnlijk twee regels in die dialog staan, 1 voor je gecompileerde DLL en 1 voor je DLL project.

[PoweRoy]

als ik kijk bij het aanroepende exeproject => reference, vink ik de NavisionPL.dll uit. Dan op Ok, daarna nu toevoegen via browse => navisionPL.dll.

of moet ik via een andere manier doen?

Verrek, heb nu de vbp toegevoegd ipv de dll en het werkt

Even een notitie van maken voor mij en het bedrijf

zwaar irritant omdat ik er vanaf 10uur al tegenaan zat te bonken

[ Voor 38% gewijzigd door PoweRoy op 12-04-2006 13:57 ]

[RobIII]

In het menu "File" heb je behalve "Open project" ook "Add project". Is helluva lot easier dan zo'n los bestandje te maken. Add gewoon het DLL project, set je breakpoints et voila.

[ Voor 14% gewijzigd door RobIII op 13-04-2006 03:06 ]

[Verwijderd]

Wat ik ook vaak doe als ik aan het ontwikkelen ben. Eerst alles in een exe bouwen en die later omzetten naar een dll

Wat ook kan is een (activex) dll als activex exe laten starten, even een module aan je project toevoegen met een sub main die de juiste procedure aanroept.

[ Voor 42% gewijzigd door Verwijderd op 22-04-2006 20:42 ]

[farlane]

VB is wat dat betreft zo gammel als maar kan. Volgens mij is dat een gevolg van het hele GUID gebeuren wat niet meer klopt, of wel de GUID maar niet de interface van de dll waarbij die GUID hoort.

Conclusie: COM zuigt, VB ism COM nog harder

[RobIII]

farlane schreef op zondag 23 april 2006 @ 20:18:
VB is wat dat betreft zo gammel als maar kan. Volgens mij is dat een gevolg van het hele GUID gebeuren wat niet meer klopt, of wel de GUID maar niet de interface van de dll waarbij die GUID hoort.

Conclusie: COM zuigt, VB ism COM nog harder

Bull. Ik heb vele, vele COM-dll's gemaakt en heb er nooit problemen mee gehad. Kwestie van SP5 of hoger gebruiken, de documentatie een keer lezen, project compatibility een keer uitpluizen en gaan met die banaan. Werkt prima, ook tijdens debuggen enzovoorts.

Dat VB6 nog stamt uit 1802 is tot daar en toe, en het kent zeker zijn beperkingen. Maar ik vind dat je "onkunde" (wat dat is het als je het niet "goed" aan de praat krijgt) in dit geval niet op VB6 mag schuiven.

[ Voor 16% gewijzigd door RobIII op 23-04-2006 22:28 ]

[farlane]

RobIII schreef op zondag 23 april 2006 @ 22:27:
[...]

Het is niet zo dat ik niet de docs gelezen heb of VB6 voor de eerste keer opstart of weet ik veel wat. ( Over VB6 an sich heb ik helemaal niets gezegd dus het is niet nodig om je persoonlijk aangevallen te voelen, of het meteen op onkunde van mijn kant te schuiven. )

Het is trouwens ook geen onbekend probleem dat VB6 van COM componenten ( dll/activex weet ik het ) die met verschillende versies op het systeem staan een potje maakt.

( Zie onder ander hier http://www.angelfire.com/...l.html#UnavailableVersion voor een verhaal dat voornamelijk over common controls gaat, maar bijvoorbeeld het gedeelte over de typelib cache van VB gaat voor elk COM component op )