8

I am trying to start making my own libraries avaialble as packages prior to compiling my Apps with these packages hence modularising my code. For years I've 'sort of' understood packages, breathing a sigh of relief when I load a component package and click on 'Install' and it does. I understand that the process of installing a component (or components) is via the creation of a BPL which is then registered with the IDE.

Where I begin to get lost is how to make files available so that I can compile with EITHER a package OR pre-compiled dcu's (like the third party vendors do) and without pointing my project at the source code all the time. I can create a package with the following settings:

enter image description here

where I've specified that all my output will go into 'c:\scratch\wow'. After a build I find TEST.BPL, TEST.DCP and lots of DUC's. Now, when I point another project at this folder to use the DCU's, I get a missing DFM error (one of the units is a form). Should I be manually copying needed DFM's into this output folder? The DPK knows about this form, so why do I not get the DFM copied for me? I presume that using TEST.BPL, that file contains everything, but I wish to work in the two modes. Of course I can get around this by including the source folder in my project search path to find the DFM but third party libraries seem to already have the DFM's in their output folder. Did they install them there using the installer? Thanks

instead

4

4 に答える 4

10

As others say you could use post-build events to copy your DFM files into place. Other people use a one-time external batch file that copies the DFMs to the DCU folder.

Personally I see very little benefit to making packages for things which are not developed also as reusable components. I also see very little benefit in partitioning an existing application into packages, when you don't reasonably need to use the same subsection or package more than once, or at designtime.

Things I would put into packages:

  1. Delphi visual and non-visual components.

  2. Things which absolutely must be plugged in at runtime, or left out. For example, supposing I sell MetaWare Light and MetaWare Pro, and instead of using compiler IFDEFs to build a differnt binary, I preferred for some reason to simply not ship the ADVANCEDFEATURE.BPL with my systems.

Things to beware of with packages:

  1. I have run into a lot of compiler bugs when combining packages with generics. I have also run into IDE crashes and lockups, in Delphi 2009, 2010, XE and XE2. (I believe XE3 is better)

  2. You should learn a bit about BorlandMM.dll and shared memory management in the BPL world before you move to it. There are some subtleties.

  3. Packages limits the ability of the linker to decide what to remove. In fact, it pretty much destroys it. Packages contain everything that is linked into them, and nothing publically accessible can be removed.

  4. Once you've created a binary package and shipped it to even one customer, you have a pretty difficult to modify contract (this BPL contains a particular signature or application binary interface) you have to be careful in the future to never change them, or mix and match them. Beware of DLL hell, even among your own customers, and be prepared to use versioning on your packages. Just as delphi packages have a version suffix, I recommend you use version suffixes in your own packages right off the bat, and bump them whenever binary compatibility has changed.

  5. Delphi handles build dependencies between packages about as well as could be hoped, which is less well than a single monolithic application. In applications that I have that make heavy use of packages, I find project groups that contain a bunch of packages that depend on each other are very difficult to manage and build quickly. In fact, I have experienced that both compiles and builds are slower and more frustrating than they would be in a singular 750Kline megaproject.

I really wonder if you're not that into the package area of Delphi (you breath a sigh of relief whenever a delphi component actually builds and installs without issue?) if you really want to move into the Packages World totally. By all means, you should experiment. But I wouldn't bet the farm on it yet. Learn some more first.

于 2011-07-24T18:44:31.743 に答える
5

Yes, you should copy the .dfm to the directory with the compiled units (.dcus), if that is the only directory you want in your search path. The BPL will of course contain the .dfms, and you need a .dcp to be able to link a BPL with your app.

Third party tools must have put the .dfms together with the .dcus in the directory using their installer, indeed.

于 2011-07-24T17:58:55.503 に答える
2

Instead of copying *.DFM manually you can use Post-Build Event (Project/Options/Build Event), ex:

copy “$(PROJECTDIR)\Unit1.DFM” “c:\Scratch\wow\Unit1.DFM”
于 2011-07-24T18:00:49.327 に答える
0

.dfmファイルを.dcuファイルのディレクトリに移動せずにこれを行う方法を見つけたので、.dcuファイル専用のディレクトリを.dcpファイル専用のディレクトリと.bplファイル専用のディレクトリにすることができます。

私がするように、あなたがする必要があるのはあなたの良い構造に別のディレクトリを作成することです。このディレクトリはRESと呼ばれ、パッケージ（コンポーネント）を使用してコンパイルされたアプリケーションで使用されるすべてのリソースファイル（.dcrファイルではなく.resファイル）を配置する必要があります。Delphiライブラリパスには、DCUディレクトリ（すでに持っているはずです）に加えて、RESという名前のディレクトリを含める必要があります。

コンポーネント（設計時）で、フォームを使用して必要なすべてのことを実行します（設計、他のコンポーネントの配置など）。ユニットのソースコードで、{$ R*.dfm}を{$RUnitName.dfm}に置き換えます。その際、すべてを保存してDPKを閉じます。次に、.dfmファイル（コピーしないでください、移動してください！）をRESフォルダーに移動し（.dfmファイルはDelphiのリソースファイルです。{$ R}ディレクティブは証明です！）、その後、DPKを再度開いて理解します。変化したこと。

「DFMがありません」というエラーがDelphiから発行されていなくても、彼のユニットからフォーム（F12）を開かない可能性があることを最初に認識してください。

次に、パッケージでビルドを実行してからインストールします。再び実現しましたか？エラーは表示されません！これは、Delphiライブラリの検索パス（RESディレクトリ）で.dfmファイルの場所を指定したために発生しました。

終わり！コンポーネントを使用できます。dfmは、コンポーネントがアプリケーションに含まれているときに検出されます。

これで、コンポーネントの設計時にフォームを視覚的に編集できなくなると多くの人が言うことができます。はい、これは本当ですが、考えてみれば、フォームをコンポーネントに頻繁に変更して、実際には使用して少し編集するだけでよいのはなぜですか？あなた自身の結論を導きなさい;）

于 2011-07-26T02:06:02.390 に答える