Optimize included files and uses in Delphi - delphi

I try to increase performance of Delphi 2007 and Codeinsight.
In the application there are 483 files added in the DPR file.
I don't know if it is imagination but I feel that I got better performance from Codeinsight by simply readd all files in the DPR.
I also think (correct me if I'm wrong) that all files that are included in a uses section also should be included in the DPR file for best performance.
My question is, does it exists a tool that scan the whole project and give a list what files are missing in the DPR file and what files can be removed? Would also be nice to have a list of uses that can be removed in the PAS files.
I found Pascal Analyzer that seems to be a good tool. Comments about this specially in this case is appreciated.
A related question is here.
Regards

Regarding the unused units: cnWizards contains a uses cleaner which works very well

From the same editor as Pascal Analyser, ICARUS is free and do this job in the simplest way.
http://www.peganza.com/#ICARUS

Related

Install x-superobject (.pas file) on delphi xe6

I want to use x-superobject, but I can't figure out how to add it and use it on delphi xe6. I found one answer on how to install .pas files on delphi, but it is for delphi2010 and thing are a little bit different I think (I've tried that one but it didn't worked.)
So, to install xsuperobject I downloaded this two files and saved them. I don't know how to proceed, and I feel a bit stupid but I don't understand what is here on the wiki.
Thank you!
X-SuperObject is a runtime library, not a visual component library. The installation is quite easy.
Way 1: Simply put the two files to your project source folder and then you are able to use them without any problems.
Way 2: If you hate to include the files to any of your projects, you can open the Option dialog and goto Environment Options > Delphi Options > Library. You add the path of X-SuperObject to the Browsing Path.
Now you are able to include XSuperObject as any other Delphi native units (i.e. Winapi.Windows, System.SysUtils).

How do I Organize Shared Units in modern Delphi?

For over a decade, I have been stuck (lovingly) on Delphi 6 and have developed hundred of thousands of lines of code in a logical (to me) unit structure, where a project tends to be a few hundred lines of code referencing high-level work routines in my "library". In trying to migrate to XE5, I just can't find a way to have all my library units compiled in one place on the search path, and then just used by the project (and recompiled if necessary), but that the dcus are off with the library source rather than in with each individual project.
I'm just starting to accept that "hello world" takes 2.5Mb in XE5, and I can't stand the idea that each library unit has to be separately compiled into dcus at the project level. In the "old" days, these unit dcus would sit next to the pas files and not be recompiled if nothing changed in the source file.
The obvious place to look is the Project options, but I can't find the right setting to make the project stop keeping copies of each dcu.
I am vaguely aware that multi-platform development will cause restructuring, but I can't help feeling that there is some compromise position.
There must be something big I am missing.
Starting in Delphi XE2, Delphi supports compilation for multiple platforms, as well as different build configurations. Because of this, Delphi needs to create DCU files for each combination. For example, Win32, Win64, and OS-X DCU files are saved in separate folders by default. Otherwise, if it weren't like this, the DCU files would overwrite each other, which you should avoid (if you use different configurations/platforms).
These settings can be changed in the Project Options in the very first section Delphi Compiler by modifying the Unit output directory. This is by default .\$(Platform)\$(Config) which creates a subfolder for the platform, then another subfolder for the config, for example \Win32\Debug\. Careful for the Target at the very top, which by default is set to your current platform/config. You would typically want to first change it to All Configurations. If you clear this field completely from the options, it will produce your default behavior from older versions.
It sounds like you should create a Package. This would allow you to group all your "library" units together in one place (BPL). This package can then be installed into your IDE, and if you have any components, those components can then be installed into your component pallet.
Or you can do without a package too. All the units from all these different projects should be moved to this central place though - a single folder containing all your "library" units. This way it's less maintenance, and you can just add that one folder to your global library path.
If you put your files in a central folder, and use those files from a project, the DCU files for both the project and this "library" will be saved for that project. Delphi doesn't know that these files are a "library", it just knows that you're using them, and since it can't find an already compiled version of those units, it creates one in your project. If you want the DCU files to be saved only once and in this central place, then you would need a package.
First, let me thank all the respondents to this question - all provided useful insight. I experimented with the various suggestions (including breaking XE5 so badly that I had to reinstall -- at least I learned some areas not to mess with.)
Important to me, but a known bad coding practice, is having individual projects edit shared library units (only my own units - I do not mess with code belonging to Delphi or 3-rd party). This is critical to having multiple applications working on the same data, but in bite-sized pieces. the shared code lets me make high-level pieces of an app available to other projects. There might be better ways (I would love to hear about them), but this has worked for me for a long time.
The multi-platform model really requires the dcu structure used by default, so I will adapt to it. Share the source code, but accept multiple compilations to individual projects. A good suggestion by JensG is just to clean up the dcus when the project is not actively being worked on. Should be straight-forward utility program.
The D6 -> XE5 migration (which will take months for some of the less used areas) requires me to know which units compile successfully, so I will maintain one project whose function is to include all units and recompile them all. This will make it practical to map library unit pas files to dcu files.
The AnsiString/AnsiChar <-> String/Char problem is the major migration problem area. Simply making edit-level changes may get the code past the compiler, but there is no guarantee that the code still works the same way. Especially troubling is at interface points to Windows calls and such. My answer will be to make the units compilable first, but then write test code for trouble areas. This is what will take the months - I need to get on with new stuff, as well as fixing the old. I REALLY don't know yet if I will be able to substitute the XE5 compatible code back into Delphi 6 without another layer of testing. I THINK it should work, but it will take careful checking.
A second major migration problem is 3rd party code such as VCLZip. XE5 has its own zip support, but I have a lot of places where I use VCLzip and the conversion will not be trivial. For this specific library, it may be possible to find XE5-level source and simply work it in. There are other pieces of code gotten from the internet that I used, but never needed to truly understand which will cause significant hassles.
Again - thank you to all. This has been an interesting 24 hours. Howard

Storing scripts as a resource

I have a few scripts that I would like my program to work with. However, I would like to know if it is possible for me to store these scripts (eg. batch, javascript, vb scripts etc) in my application as a resource.
How would I go about doing this?
You can store your scripts in resource files. But for example Batch Files need to be file on disk, so you will need to unpack them before working.
There are components to store arbitrary file/files or string in DFM
For example there are such in rxLib/JediVCL but i believe many VCL libs have one or another kind of DFM Storage component.
For example i used to store Firebird Embedded database in DFM to save it into TEMP and use while running.
However that is akin for manual re-reading file into DFM each time you update it. Rather annoying to say sincerely.
One more approach is linking text into resources. You can look into DUnit sources to see how it was done. You would also have .rc file included in project, so that it would be compiler into .res when making .exe
This approach is fragile towards ansi/unicode text interpretations.
Frankly, before i found DUnit in Delphi XE2 (it was disabled due to IDE bug) i tried to make SF's vanilla DUnit to run there. And i failed - the non-unicode text files linked into resource was totally corrupt when reading with unicode-enabled Delphi.
Look here and there, try both approaches and choose the one that suits you more.
Here is a good article that explains how you can add almost anything in a resource file and compile it with your application: http://delphi.about.com/od/objectpascalide/a/embed_resources.htm

Include files in ridl

The Delphi project I'm working on requires me to create a very large type library in order to add COM support. The problem is with the type library/ridl editor in Delphi is that it becomes difficult to manage (from a programmer point of view) such a large file, and I'd like to split it along functional lines. The problem I have is that I cannot see a way to include one ridl file in another. I'm aware of the importlib function, but I also cannot find a way to create more than one type library in the same project, or create a tlb file from within delphi. Can anyone give me ideas on how to better manage this?
Standard IDL has an include statement for pulling in other files into the TypeLibrary compilation. RIDL stands for REDUCED IDL, so it might not support it, though. You will have to try it and see.

How do I compress multiple files into a single archive with Delphi

I need to compress multiple files into a single archive using Delphi. I'd prefer to use freeware components or open-source components because I am very very cheap :-)
My primary requirements are:
Possible to encrypt the archive
Can create common archives that can be opened by anyone with a copy of WinZip
Does anyone have suggestions with components that they have used? Please feel free to suggest free as well as commercial components/libraries.
Perhaps DelphiZip is what you are looking for, it seems to support encryption, too, and is WinZip compatible. It is released under LGPL.
KaZip is an open-source ZIP archiver. Here is its description:
KAZIP is fast, simple ZIP archiver and
dearchiver which uses most popular ZIP
format.Inflate - Deflate zip
compression format (no encryption
support and no multidisk
support).KAZip is totaly based on
Delphi VCL - no DLL, ActiveX or other
external libraries.KAZip is totaly
stream oriented so you can deal with
data only in memory without creating
temporary files, etc. If you need to
add zip-unzip functionality to your
application,KAZIP is the right
solution. Additional ZipListView and
ZipTreeView components for easy
visualisation.Functionality:Zip-Unzip
using Inflate-DeflateBZip2 unzipping
trough usage of BZIP2 units from
Edison Mera Menndez.Functions:Adding
Files, Folders, Streams; Selecting,
Deselecting, Checking;Extracting to
files and streams;Delete and Rename
filesCreate, Delete and Rename
foldersTest, RepairMany new properties
and methods, improved speed.A very
complex Zip Browser demo application
is included
It is not compatible with Delphi 2009 yet, but with some minor changes in the source code, you can make it work in Delphi 2009 too. Actually, that's what I did.
Regards
I`m using madZip from madCollection
I'm surprised no-one has mentioned JclCompression yet - it's part of the well-known Jedi Code Library (JCL).
Here's a view of the unit itself : http://jcl.svn.sourceforge.net/viewvc/jcl/trunk/jcl/source/common/JclCompression.pas?view=markup
Note, it's compatible with 7-zip DLL version 4.64 - newer versions might not be backwards-compatible...
I recommend the $69 ZipForge from ComponentAce.
You could use 7zip (LZMA) bindings for Pascal (compatible with Delphi): http://www.birtles.org.uk/programming/
Another Delphi resource to look at would be InnoSetup. The source code is available and with a little work might give you an edge up on what your trying to do. There is an option to create self extracting zip archives which are compatible with WinZip,
My thoughts are not to use the program, but to use his source as a starting point since it is very heavily tested and extremely solid.
There are infozips zip32 and unzip32 dlls. They can be used from Delphi (even from Visual Basic), there are interface units/modules for both. The interface isn't as good as I would have liked it, but it works.

Resources