Ik maak een DLL en wil dat op geen enkele manier Vcl.Forms daarin zit.
Is er een manier om alle unit dependencies van een project te zien?
Groet!
Ik maak een DLL en wil dat op geen enkele manier Vcl.Forms daarin zit.
Is er een manier om alle unit dependencies van een project te zien?
Groet!
Heeft GExperts daar niet wat voor?
http://www.gexperts.org/tour/index.h...endencies.html
Alternatief zou zijn om in je DLL een stukje code toe te voegen om de RTTI te scrapen en te kijken of TForm er in zit.
1+1=b
Een MAP file lijkt me dan makkelijker dan via RTTI. En het scheelt code ;_)
Ik denk dat je daar ook een aardig indruk kan krijgen wel units ingelinkt zijn.
Je kunt achteraf (na compilatie) ook in de resource van de DLL kijken of "Forms" in RCDATA - PACKAGEINFO staat.
TMemoryLeak.Create(Nil);
Of een lege Vcl.Forms.pas opnemen in je project.
Dan merk je zo of die gebruikt is
thanks! ik zal laten weten wat mijn vindresultaten zijn :-)
MMX Code Explorer heeft ook een mogelijkheid om unit dependencies in kaart te brengen.
https://www.mmx-delphi.de/screenshot...-dependencies/
Het blijkt (na handmatig gedoe), dat de printers unit Forms meelinkt. Maar nog steeds vind ik Forms (via RTTI).
Toch maar eens zoeken naar GExperts...
GExperts kan alleen "mijn" units zien in de dependencies.
Dus ik kan met geen mogelijkheid ontdekken waarom Vcl.Forms en Vcl.Controls meegelinkt wordt.
Ideeen welkom...
- Genereer een MAP file. (compiler options->linker subtab)
- bepaal een effectieve unit lijst hieruit.
- zie of je bepaalde units die je niet verwacht erin staan, en check deze. (b.v. clipboard of zo) die ook andere delen kunnen binnentrekken
- Vind je geen clues, loop alle units af en check de source.
Let op tools als gexpert, fastmm4 en jcldebug gebruiken vaak ook een van deze features:
- debug information, local symbols,debug dcus op het compiler options->compiler subtab.
- debuginformation op het compiler options->linker subtab (td32 debug info in oudere Delphis)
- de map files
- inlining uit kan in sommige gevallen ook helpen, maar dat is meer voor tracebacks, niet belangrijk voor dit geval.
Controleer de randvoorwaardes van zulke tools, en zorg dat de instellingen matchen!
Last edited by marcov; 27-Feb-20 at 16:19.
ah great. dank!
En zonet ontdekt dat Vcl.SvcMgr forms gebruikt. Insane... Dan maar geen eventlogging.
Forms is er nu uit
Wel nieuwsgierig waarom je per se geen Forms wilt gebruiken, wat daarin zit dat roet in het eten gooit voor je DLL.
1+1=b
(Een TService is ook een TApplication, en die kraam zit allemaal in forms, dus dat is op zich wel logisch denk ik.)
Het grappige is dat Vcl.SvcMgr z'n eigen application variabele heeft, met z'n eigen CreateForm method, die of een service class maakt, of de instructie doorgeeft aan Forms.Application. Als je Vcl.SvcMgr toevoegt aan je uses, na Forms, dan krijg je dus die versie, zonder dat je het verder merkt, als een augmentation van de forms unit. Op zich niet gek, aangezien service applicaties in principe desktopapplicaties zijn (of kunnen zijn), die zowel een UI kunnen hebben als als service draaien, maar wel jammer dat er geen mogelijkheid is om het los te doen. Het zou denk ik beter zijn als er een meer generieke application is, waarin zowel Vcl.Forms als Vcl.SvcMgr hun eigen aanvullingen kunnen registreren.
1+1=b
Ik probeer de DLL zo klein mogelijk te krijgen.
Maar we komen toch nog aan de 4 MB. Work in progress.
Vreemd, want het is toch een windows call? Ik moet even onderzoeken wat er kan, want een fatal exception loggen op een server is misschien wel handig.
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks