問題タブ [bpl]

C++ の Borland Builder 6 で開発しています。そして、「Components」/「Installer des paquets」をクリックすると、パッケージ dclIndy60.bpi が表示されます。「Internet Direct (Indy) for D6 Property and Component Editors」は、すべて問題ないことを意味します。 Indy60 パッケージ (Indy9 フォルダー内: 2002 年 11 月付けの indy のバージョン 9) で、古い「indy」パッケージ (私の BCB6 インストール ディスクのデフォルト バージョン) は使用しなくなりました。

私の問題は、明らかに古い Indy.bpi パッケージ (私の場合は Indy60 の代わりに) を使用してコード化された "old_project" をコンパイルしようとすることです。コンパイル中に次のようなウィンドウが表示されます。 : indy.bpi"、参照ボタン付き。次に、私が持っている唯一の「indy」bpi ファイル、Indy60.bpi を参照します。

実際、私は（ように見えるように）indy9を正常に再インストールしました。最初に古いindyのすべての痕跡（フォーラムでアドバイスされているように）と必要なindy 9を削除してから、indy 9を再度インストールします（BCB 6ディスクを使用して古いindyを削除します） ）。そして、私の「old_project」では、（上記のように）「コンポーネント」メニューで indy60 を指していることを確認しました。しかし、コンパイル時に「indy.bpi」を要求します。

=> この古い indy.bpi への参照を削除したり、新しい "indy60.bpi" に置き換えたりするにはどうすればよいですか?

=> それとも、 indy.bpi と indy60.bpi の違いをひどく誤解していますか? それとも、Borland Builder の bpi と bpl の管理で混乱を招きすぎているのでしょうか?

=> または、新しいプロジェクトを作成し、古い BCB C++ プロジェクトからファイルごとにコピーした方がよいでしょうか?

混乱を招いて申し訳ありません。私は C++ アプリケーションをゼロから開発するのは少し初めてで (既に作成されたアプリケーションの保守に 3 年の経験があります)、Borland Builder も初めてです。

よろしく、アルノー。

私はアプリケーション用のいくつかの外部モジュールを開発しています。

これらのモジュールはBPLファイルであり、アプリケーションフォルダーに存在する場合、アプリケーションはそれらをロードし、内部で利用可能なものをすべて使用します。

クライアントによるこれらのモジュールの共有を防ぐにはどうすればよいですか？

モジュールの使用を許可する必要があります（モジュールごとに）。

ある種のライセンス、モジュールの登録を取得するには、どのような方法が最適ですか？

ありがとう

私は、BPL を動的にロードし、オブジェクト インスタンスをメイン アプリから BPL のメソッドに渡すというアイデアをいじっていました。これにより、アプリケーションで使用されるユニットと BPL で使用されるユニットの間で問題が発生します。

私はこれを行う小さなプロトタイプを作成し、Delphi がアプリで定義されたクラスと BPL で定義されたクラスの間の違いを内部的にどのように管理しているかに興味を持っていました。

たとえば、次のような基本的な Widget クラスがあるとします。

これで、TmyWidget クラスを含むユニットを使用して、アプリと BPL がビルドされました。その後、TMyWidget で何かが変更され、アプリが再構築されましたが、BPL はそうではありません (またはその逆です)。別のメソッド DoSomething2() を追加し、アプリで TmyWidget のインスタンスを作成し、処理のために BPL に渡しました。基本的な例、うまくいきました。しかし、それは明らかに潜在的な問題をはらんでいます。

動的にロードされる別の BPL も TmyWidget を使用する場合、事態はさらに興味深いものになります。機能しているように見えますが、理想的ではありません。

主な質問は、通常、メイン アプリケーションと DLL または BPL との間でオブジェクトをどのように受け渡すかということです。これまでに試みたことはなく、おそらく正当な理由がありますが、このアプローチに役立つこのアイデアを思いつきました...

最良のアプローチは、オブジェクトをシリアル化し、それらのバイトを渡し、DLL/BPL で逆シリアル化することだと思いますが、このプロセスでは、ホストと動的に読み込まれるモジュールの間の潜在的なバージョンの違いに注意を払っていますが、新しい SimpleSharedMem を望んでいましたオプションは、シリアル化のオーバーヘッドなしでこの新しい機能をもたらす可能性がありますが、共有コードの変更に合わせてアプリと dll を再構築することを厳密に維持しない限り、あまり役に立たないようです...しかし、このプロトタイプでは、アプリはかなり一定のままですまた、動的にロードされるモジュールは、TmyWidget に機能が追加されて頻繁に変更されます。(サーバー アプリは、クライアントの要求に基づいて TmyWidget を構築するためのファクトリとして機能し、アプリは処理のためにさまざまなモジュールにインスタンスを渡します。)

EXE にリソースがあり、それを抽出したい場合、それは非常に簡単です。何かのようなもの：

これが機能するのは、グローバル変数 HInstance が EXE へのハンドルであるためです。BPL 内のコードがその一部であるパッケージへのハンドルを取得して、そこからリソースを抽出できる同様の方法はありますか?

私が働いている会社は、Delphiでシステムを開発しています。このシステムには、数十のexeモジュールが含まれており、ソースコードに関しては、それぞれがある程度同一です。悲しいことに、誰もライブラリを使用して共有コードを挿入することを気にしませんでした。つまり、これらすべてのモジュールが共有するコードでバグ修正を行うたびに、プログラマーはそれらすべてを個別に修正する必要があります。いつもとても時間がかかります...

共有コードをライブラリに入れる方法を見つけることにしました。DLLとBPLを検討しました。この場合、BPLはプログラマーにとってはるかに使いやすく、面倒ではないように見えました。特に、コードがソフトウェアでのみ使用され、Delphiでのみ使用されていることがわかりました。

すべてのexeモジュールで共有されているすべてのコードをBPLに入れて、すべてがうまくいくように見えますが、理解できないことがいくつかあり、説明していただければ幸いです。

1. コードをBPLに分割した後、私が期待したのは、作成したBPLを使用してexeファイルを展開するだけで十分であるということでした。しかし、rtl100.bplとvcl100.bplも必要であることが判明しました。なんでそうなの？exeとBPLのみをデプロイしたい。ボーランドやサードパーティ企業が提供する大量のライブラリをエンドユーザーに提供したくありません:)。以前にコンパイルされていたので、exe内でコンパイルしてほしい。それは可能ですか？

2. 私がこれまでにしたことは次のとおりです。

   • すべての共有pasユニットをBPLに配置しました。各BPLには同じカテゴリに属する​​ユニットが含まれているため、プログラマーは特定のBPLでどのコードを期待するかが明確になります。
   • 各BPLは、「ランタイムおよびデザインタイム」ライブラリです。
   • 各BPLは「明示的に再構築」されます。後者の2つは、BPLのデフォルトのプロジェクト設定です。

3. そして、exeプロジェクトに関しては：

   • 以前にBPLに配置したすべてのユニットを削除しました。
   • BDS2006の[ツール]->[パッケージのインストール]メニューからBPLをインストールしました。
   • exeプロジェクトの設定で、[ランタイムパッケージを使用してビルドする]オプションをオンにし、下の編集ボックスにすべてのBPLパッケージを一覧表示しました（そこに表示される他のすべてのパッケージをクリアしたため、パッケージのみ）。

これが私がしたすべてです。exeプロジェクトは正しくコンパイルされますが、すべてのBPLがソースコードファイルと一緒に保存されていても、BPLのソースコードにアクセスできません（exeプロジェクトからそのコードに移動できません）。なんで？それは私には奇妙に思えます。

私はいつも長い説明を書く傾向があります-申し訳ありません:)。よろしくお願いします。私が言及したポイントについて、いくつかの説明が必要です。BPLのみを使用してexeを展開すること、全体として行ったことの正確さ、およびBPLソースコードに移動できないことです。事前にどうもありがとうございました！

議論してくれてありがとう。私が選んだアプローチは良い考えではないと言う人もいました。私たちのソフトウェアは100以上のモジュールで構成されています（それらのほとんどはさまざまなデバイスのドライバーのようなものです）。それらのほとんどは同じコードを共有します-ほとんどの場合クラス。問題は、これらのクラスが常に個別のスタンドアロンpasユニットに配置されるとは限らないことです。つまり、共有コードは、モジュールに固有のコードを含むユニットに入れられることがよくあります。つまり、共有クラスのバグを修正する場合、それが定義されているpasユニットをすべてのソフトウェアモジュールにコピーして再コンパイルするだけでは不十分です。残念ながら、固定されたコードを1つずつコピーして、適切なユニットとクラスに貼り付ける必要があります。これには多くの時間がかかります。これは私が排除したいことであり、正しいアプローチを選択します。助けてください。

BPLを使用することは良い解決策になると思いましたが、一部の人が言及したように、いくつかの欠点があります。最悪の問題は、各EXEに複数のBPLが必要な場合、テクニカルサポート担当者がどのEXEにどのBPLが必要かを把握し、エンドユーザーに適切なファイルを提供する必要があることです。ソフトウェアアップデーターがない限り、これは技術者とエンドユーザーの両方にとって大きなメリットになります。彼らは確かに迷子になって怒ります：-/。

また、互換性の問題が発生する可能性があります-1つのBPLが多くのEXEで共有されている場合、1つのBPLの変更は、1つのEXEには有効であり、他のいくつかのEXEには不利になる可能性があります-@WarrenP。

非常に多くのプロジェクトでバグ修正をより迅速に行うには、どうすればよいですか？私は次のアプローチの1つを考えます。もっと良いアイデアがあれば教えてください。

• 共有コードを個別のスタンドアロンpasユニットに配置します。そのため、そのうちの1つにバグ修正がある場合は、それをすべてのプロジェクトにコピーして（古いファイルを上書きして）、すべてを再コンパイルするだけで十分です。

この解決策は、後から変更されたコードが具体化されている限り、問題ないようです。しかし、一般的な使用機能と手順を備えたpasユニットもあります。これは、多くの場合、変更を取り消すものです。必要に応じて、単一のプロジェクトで新しい機能を追加します。したがって、100個のモジュールの1つに新しい関数を記述し、それを汎用ユニットに配置するとします。1、2か月後、別のモジュールを変更し、2か月前に作成したものと同じ関数が必要だと思います。モジュールを見つけて（それがどれであったかを覚えていないと難しい）、関数をコードにコピーする必要があります。そして明らかに、一般的な使用単位は、各プロジェクトに個別に保存されている限り、モジュールごとに完全に異なります。そして、実行するバグ修正がある場合...全体の話が繰り返されます。

• すべての共有コードのBPLを作成しますが、EXEをスタンドアロンにするために、それらをEXEにリンクします。

私にとっては今のところ最善の解決策のようですが、いくつかの短所があります。BPLでバグ修正を行う場合、各プログラマーは自分のコンピューターのBPLを更新する必要があります。彼らが忘れたらどうしますか？それでも、それは小さな問題だと思います。変更についてお互いに通知するように注意すれば、すべてがうまくいくはずです。

• @CodeInChaos：あなたを正しく理解したかどうかはわかりません。プロジェクト間でpasファイルを共有するという意味ですか？どうやってするか？ソースコードはSVNに保存されます。つまり、共有コードを別のフォルダーに保存し、すべてのプロジェクトでそのコードを検索する必要がありますね。そして、SVNからプロジェクトとそれが依存するすべてのフォルダーをダウンロードします...

どうか、私が良い解決策を選ぶのを手伝ってください。ソフトウェア開発への愚かなアプローチのために、バグ修正で必要以上の時間とお金を会社が失うことを望んでいません。

どうもありがとうございます。

これは、私がここで始めた議論の続きです。この分野の経験がないため、Delphi ソース コードをモジュール化する最善の方法を見つけたいと考えています。私はあなたのすべての提案に感謝します。

私がすでにそこに書いたことを投稿させてください。

私が働いている会社が開発したソフトウェアは、100 以上のモジュールで構成されています (そのほとんどは、さまざまなデバイスのドライバーのようなものです)。それらのほとんどは同じコード (ほとんどの場合クラス) を共有しています。問題は、これらのクラスが常に個別のスタンドアロン PAS ユニットに配置されるとは限らないことです。共有コードは、モジュール固有のコードを含むユニットに入れられることが多いということです。これは、共有クラスのバグを修正する場合、それが定義されている PAS ユニットをすべてのソフトウェア モジュールにコピーして再コンパイルするだけでは不十分であることを意味します。残念ながら、固定されたコードを各モジュールに 1 つずつコピーして、適切なユニットとクラスに貼り付ける必要があります。これには多くの時間がかかります。これは、正しいアプローチを選択することで、近いうちに排除したいものです。助けてください。

EXE と共に配布される BPL を使用することは良い解決策になると思いましたが、前の議論で述べたように、いくつかの欠点があります。最悪の問題は、各 EXE が複数の BPL を必要とする場合、テクニカル サポート担当者が、どの EXE がどの BPL を必要とするかを把握し、エンド ユーザーに適切なファイルを提供する必要があることです。ソフトウェア アップデーターがない限り、これは技術者とエンド ユーザーの両方にとって大きなメリットとなります。彼らは確かに迷子になり、怒るでしょう:-/.

また、互換性の問題も発生する可能性があります。1 つの BPL が多くの EXE で共有されている場合、その BPL の変更は、1 つの EXE には有効で、他の一部の EXE には無効になる可能性があります。

非常に多くのプロジェクトでバグ修正を迅速に行うにはどうすればよいでしょうか? 以下のいずれかの方法が考えられます。より良いアイデアがあれば、お知らせください。

• 共有コードを個別のスタンドアロン PAS ユニットに配置して、そのうちの 1 つにバグ修正があった場合、それをすべてのプロジェクトにコピー (古いファイルを上書き) し、すべてを再コンパイルするだけで十分です。これは、各ユニットが使用されているプロジェクトの数だけコピーされることを意味します。

めったに変更されないコードに関する限り、この解決策は問題ないようです。しかし、一般的な機能と手順を備えた pa ユニットもあり、これらはしばしば変更されます。誰かが新しい関数をこのファイルに追加するたびに、同じ手順 (非常に多くのプロジェクトをコピーして再コンパイルする) を行うことは不可能です。

• すべての共有コードの BPL を作成しますが、それらを EXE にリンクして、EXE がスタンドアロンになるようにします。

私にとっては、これが最善の解決策のように思えますが、いくつかの短所があります。BPL でバグ修正を行った場合、各プログラマーは自分のコンピューターで BPL を更新する必要があります。彼らがそれを忘れたらどうしますか？ただし、それは小さな問題だと思います。変更についてお互いに通知するように注意すれば、すべてがうまくいくはずです. どう思いますか？

• そして、CodeInChaos によって提案された最後のアイデア (正しく理解できたかどうかはわかりません)。プロジェクト間で PAS ファイルを共有する。おそらく、共有コードを別のフォルダーに保存し、すべてのプロジェクトでそのコードを検索する必要があることを意味しますよね? また、プロジェクトを変更する必要がある場合はいつでも、共有ファイル フォルダーと一緒に SVN からダウンロードする必要があると思います。共有コードを変更するたびに、そのコードを使用する各プロジェクトを再コンパイルする必要があります。

良い解決策を選択するのを手伝ってください。ソフトウェア開発への愚かなアプローチのせいで、会社がバグ修正のために必要以上に多くの時間とお金を失うことを望んでいません。これまでのところ、誰もそれを気にかけたことがなく、それがどれほど多くの問題を引き起こしているか想像できるでしょう.

どうもありがとうございました。

DELPHI アプリケーション用の外部モジュール システムを実装する最良の方法は何ですか?

私が必要とするのは、本当に非常に基本的なものです:

• メインアプリは、モジュールが存在するかどうかを検出してロードします（実行時）
• モジュールはフォームを保存できます
• モジュールは DataModule を格納できます
• モジュールはコードを保存できます

ストア フォームを他のフォーム内で使用する必要があり、スタンドアローンとしてのみ使用する必要があります

私はこのようなものを使用します

そこで、TForm を作成しますが、TPanel 内に配置します。

DataModules に関しては、私は通常 ImageLists を保存するので、外部モジュールを少し変更するだけでアプリの ICO を変更することが考えられます。

では、これを達成するための最良の方法は何ですか?

ランタイム BPL を見ましたが、その方法を理解していないようです。ありがとう。

アップデート ： .....................................

関連する質問と回答をいくつか読んだ後、回答と解決策を見つけたと思います。

http://edn.embarcadero.com/article/27178

記事は古いものですが、驚くほどシンプルです。

ロジックはありますが、フォームを表示するまでには至っていないようです </p>

私はちょうど例2をテストしています

BPL をロードしますが、フォームを取得しません。

常に取得 x 'nil'</p>

しかし、登録された BPL は次のようになります。

誰でもこれを手伝ってもらえますか。

次の投稿の下書きを作成しているときに解決策を見つけましたが、参考のためにここに投稿する価値があると思いました. 以下の解決策を参照してください。

RAD Studio (C++) には、カスタム コントロールの標準セットに依存する複数の dll および exe を含むプロジェクト グループがあります。これらのコントロールを borland パッケージ (bpl) に分離して、デザイン ビューで使用できるようにしました。

カスタム コントロールの 1 つをコンポーネント パレットからフォームにドラッグすると、コンポーネントが実際にはフォームを含むプロジェクトに静的にリンクされているように見えます。これは私が望んでいるものではなく、一部のコントロールは bpl にリンクされた追加のリソースに依存しているため、問題が発生します。

RAD Studio が自動的に追加する #pragma link 行を既に削除しましたが、コンポーネントはまだ実行可能ファイルにリンクされています。これがどのように起こるかわかりません。

何か案は？

OK、ソリューションはかなり簡単です。プロジェクト オプションで、[パッケージ] ページに移動し、[ランタイム パッケージでビルド] の下に、共通コンポーネントを含むパッケージの名前 (bpl 拡張子なし) を入力します。終わり。

Delphi XEでプロジェクトを開こうとすると、いくつかの人気のあるbplパッケージで次の問題が発生することがよくあります。

パッケージ「Name1.bpl」を読み込めません。コンポーネント「Name2」は、パッケージ「name1.bpl」によってすでに登録されているため、パッケージ「name1.bpl」によって登録できません。次回プロジェクトがロードされるときに、このパッケージをロードしようとしますか？

助けてくれてありがとう！

PSキルプロセスとIDEのダブルリスタートは常に役立ちます。

XE2で単純なモジュールシステムを実装しようとしましたが、動作させることができませんでした。IDEで実行しようとすると、ハンドルを取得できLoadPackage()ますが、クラスを取得できませんGetClass()（BPLの初期化セクション内でRegisterClass（）されている場合でも）。Windowsで実行しようとすると、「rtl160.bplが見つからなかったため、このアプリケーションを起動できませんでした」というエラーが表示され、パッケージをロードすることもできません。

モジュールコード

また、「登録済み」メッセージボックスが表示されないため、初期化セクションが実行されていません。

そして、ホストアプリは次のようなものです。

ホストアプリはランタイムパッケージTrueにリンクされていました。モジュールにはランタイムパッケージオプションがありません。

別の質問。この基本的な例をネット全体で見ましたが、同様のモジュールをさらに追加する予定RegisterClass()です。初期化で2番目のモジュールのTfrModuleクラスを試してみるとどうなりますか？モジュールごとに異なる名前を付ける必要がある場合でも、モジュールの意味はありません。つまり、ホストがモジュールのクラスがどのように見えるかを正確に知る必要がある場合です。