Leaderboard

I have implemented and then expanded the feature of exporting the list of units a project uses explicitly and implicitly in GExperts: First, you need to activate the creation of a Map file in the Project Options: Then you need to activate the corresponding option in the Uses Clause Manager Configuration settings: Build your project and then, in the GExperts Uses Clause Manager, open the Project tab. 1. Click the "Copy/Save List" button to copy the list of Project Units to the clipboard. 2. Hold down the CTRL modifier key while clicking the button to save the list to Disk instead. 3. Click on the DropDown part of the button to dropdown the menu containing the same actions. Since Thomas is busy until weekend, here are the units containing my implementation (so you can build GExperts with this feature) : GX_UsesExpert2.zip

No, it's not a good practice - write your classes in a way that you could do pure DI. If you do field injection that code can't run without a DI container or some other ways to do such injection. If you have too many ctor arguments you are suffering from so called constructor over-injection and there is a way to solve this: refactor your code and respect the single responsibility principle - see https://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/ Always think of a DI container as something like an automated assembling plant - all the screws and pieces that are put together there by robots don't know of the assembling plant. You can as well grab a screwdriver or some other tool yourself and put the pieces together manually with a lot of work and sweat but it's possible.

Orthogonally to the suggestions from Pawel, I'd suggest also trying to analyse what the step is actually doing while it's "being slow", with ProcessMonitor. Even the built in Windows 10 Resource Monitor, which you can get to from the Task Manager in Windows, can be fairly useful as it allows you to isolate and drill into individual processes to monitor their behaviour as well, including handles/files opened/loaded etc etc. Understanding what it's actually doing and working out why this step is being slow might give you ideas on how to avoid it.

ok, I solved. I have created a new project and now it works!

I use them to apply the same options to all my various projects. They work quite nicely. It means that if ever I change an option, or make a new project, I can roll it out effortlessly, and with confidence.

Works fine here. Are you using the latest versions from GitHub? Are you following the instructions at https://github.com/project-jedi/jcl and https://github.com/project-jedi/jvcl?

I am not sure if the quote is actually the intended one, as Thomas description is not related to the clipboard at all. In case you are referring to the MMX solution, make sure that you copy the interface (not its methods) from the contents list of the MMX Code Explorer window and paste it into the members list of the target class.