![delphi xe findinfiles delphi xe findinfiles](https://4.bp.blogspot.com/_9sWBW4MIeFk/TG_QY1-zvkI/AAAAAAAAB3A/4384nmUhNbE/s1600/WatchList.png)
I just looped with a pattern of 60 Bytes here, that’s why i have an extra character here in front of the last name. Something to note here: The last entry, which is the DPK-Entry seems to have a Header with a length of 61. So if you’ve done everything right, you can get an output like this: The last element is always the Package-DPK unit. So to get a list of contained units here, you simply skipp 60 Bytes and read 2 strings per element based on the number of contained units in our header. I highlighted theses fields in Green/Brown and Blue/Orange. This pattern goes on with units like “”, where the NameSpace is “Foo.Bar”. But when your unit is dotted like “Foo.OtherUnit”, it’ll contain “Foo”. When your unit is not dotted, the second string is always empty and consists only of the NULL-Character. The first string is our Unit-Name, the second one seems to be some kind of NameSpace. And 2 zero-terminated strings after each block. To sum it up here, each element of this list contains of a 60 Byte-Blob i haven’t investigated, yet. After that, a list of contained units with their own header follows. So to get a list of required DCPs, you simply read zero-terminated string after zero-terminated string based on the number of required DCPs as noted in our header. This is because it is directly followed by a list of zero-terminated strings which include the names of required DCPs. Right after our BPL-Name, we’ll notice “RTL”. So to sum it up, our header looks like this in Delphi:
![delphi xe findinfiles delphi xe findinfiles](https://image.slidesharecdn.com/delphi-data-sheet2-110304132901-phpapp02/95/delphi-xe-datasheet-1-728.jpg)
The Orange box simply contains the lengths in Bytes of the BPL-Name which follows the header (Excluding the terminating NULL-Character). Wait, we have to units, why does it tell me that there are 3? Quite simple, the DPK-File of your Package (In this case TestPackage.dpk) is included in this list, too. By fiddling around, you’ll notice that Green is the number of required DCPs and Blue the number of Contained Units. Green and Blue contain numbers, which change depending on the Number of contained Units and required DCPs. The Red-Field is our Signature as discussed before. I have outline the fields i already analyzed and describe them here. So our first 32 Bytes are for sure some kind of Header. By comparing different DCPs, you’ll notice, that the BPL-Name always starts at the same position (Byte 33). And this is the place where you’ll find the final BPL-Name. For example, for VCL150.bpl only a VCL.dcp exists. This is required when dealing with BPLs which have Postfixes. This is the name fo the BPL the linker will link to. YOu may validate this when loading a file to make sure you have a DCP. Another option is to use a make file for building. Partly a problem could be solved by using an unofficial IDE Fix Pack. In our case compilation failed with the bunch of internal compiler errors, because of the memory leakage by the compiler. All DCP seem to start with it, so i declared it as our DCP-Signature. We had a pretty much the same problem while building a large (> 4mln lines) Delphi XE project.
![delphi xe findinfiles delphi xe findinfiles](https://i.ytimg.com/vi/pFyrqugIMA8/maxresdefault.jpg)
Something you’ll notice is, that the Stream starts with the 4 AnsiChars “PKX0”. Grab a Hex-Editor of your choice and look into it. This should do the job for experimenting. It requires only the RTL and has 2 empty units: MyUnit and Foo.OtherUnit. For analyzing a DCP, i created a new Package, called TestPackage.bpl. So let’s get started with our dirty work. I know that things might have changed from XE to XE8, but i hope this article is still helpfull to get anybody outside of XE started. Some searching didn’t reveal much (besides the same questions as i had). However, to do so, i had to work with DCPs, too. During the last past weeks, i wrote a Project-Analyzationtool, which is able to completely unwire all Unit-Dependencies and fix searchpathes. This includes name of BPL to link with, required DCPs and contained Units.
#Delphi xe findinfiles how to#
But, for the needs I had, this solution has worked out wonderfully and thankfully, involves a small amount of very simple code that is easy to understand and maintain.During this Article, I’ll show how to read some very basic information from Delphi’s DCP-Files. I was quite hesitant to use this approach, thinking it was far too brute-force. If I can't open it, then it's not added to the TStringList so it's checked on the next event.) (To detect if a file is closed, I try to open the file in exclusive mode. Any file that is found that isn't already in the StringList from previous TTimer events is new. All files found are put in a persistent TStringList.
![delphi xe findinfiles delphi xe findinfiles](https://i.ytimg.com/vi/j5KWtGRWSls/maxresdefault.jpg)
On a TTimer event that fires every few seconds, I use FindFirst on the folder I'm monitoring. I ended up using a surprisingly simple approach that has worked wonderfully for me. I also seem to recall that Iztok's code used threads and didn't feel light-weight enough for my needs. His code worked, but I needed to be notified at the moment a file in a specific folder was closed, which for some odd reason, the ReadDirector圜hanges API (on which it depends) from Microsoft (maddeningly) doesn't provide. He responded to email and was very helpful in answering my questions. Last year I had the same need and tried out Iztok Kacin's Directory Watch.