問題タブ [tcollection]

選択した行を内の1つのインデックスの上または下に移動するMoveItemUpメソッドとMoveItemDownメソッドを実装しようとしていTCollectionます。

TCollectionのサブクラスに追加された次のコードは機能しません。

リスト内のコレクションアイテムを並べ替える方法を提供するDelphiIDE自体によって設計時に行われるため、これは実行時に可能である必要があると確信しています。オブジェクトを作成、破棄、または割り当てずに、既存のオブジェクトを並べ替えるだけでこれを実行したいと考えています。これは、Classes.pas TCollectionのサブクラスから可能ですか？（そうでない場合は、ソースクローンから独自のTCollectionを作成する必要がある場合があります）

コンポーネントでサブコンポーネントを生成および管理するための基本を知る必要があります。私はもともと を作成してこれをTCollection試し、それぞれに名前を付けようとしましたTCollectionItem。しかし、私が望んでいたほど簡単ではないことを学びました。

だから今、私はこのプロジェクトをゼロからやり直すつもりです。これらのサブコンポーネントはビジュアル コンポーネントではなく、 に基づいているだけで、ディスプレイやウィンドウを持つべきではありませんTComponent。これらのサブコンポーネントを保持するメイン コンポーネントも に基づいていTComponentます。したがって、ここには視覚的なものはまったくありません。また、これらのサブコンポーネントごとに (設計時に) フォームに小さなアイコンを表示したくありません。

これらのサブコンポーネントをコレクションのような方法で維持および管理できるようにしたいと考えています。重要なことは、これらのサブコンポーネントを作成し、名前を付けて、フォーム ソースに追加する必要があることです。これは、たとえばメニュー項目と同じです。そもそもこれがアイデアの要点であり、名前を付けられない場合、このアイデア全体がカプットになります。

もう 1 つ重要なことは、すべてのサブコンポーネントの親であるメイン コンポーネントは、これらのサブコンポーネントを DFM ファイルに保存できる必要があるということです。

例：

これらのサブアイテムのいずれかにアクセスする代わりに、次のようにします。

代わりに次のようなことをしたいと思います:

したがって、各サブアイテムの ID を知っていることに頼る必要はありません。

編集：

元のコレクションがどのように機能するかを確認できるように、元のコードを含める必要があると感じました。以下は、完全なユニットから取り除かれたサーバー側のコレクションとコレクション アイテムです。

これは、私が尋ねた別の質問の受け入れられた回答に特に関連しています。(前の質問で説明したように) 既存のコレクションをこの新しい「名前付きコレクション項目」構造に変換しているときに、コンパイラ エラーが発生しました...

[Error] JDSockets.pas(818): Incompatible types: 'tagWNDCLASSA' and 'Class reference'

Registerこれは、最初の行の手順から来ていますRegisterClass(TSvrCommandComp);

TSvrCommandCompはTChildComponent前の回答のTJDServerSocketの私のバージョンであり、 の私のバージョンですTParentComponent。

前の回答では、実際には 2 つの単位が定義されていました。私はその概念をスキップして、それらを同じユニットに組み込みました。そして、このユニットは非常に巨大です。ここでは、可能な限り無関係なものを取り除いて以下に示します...

TComponent にカプセル化されていない TCollection をシリアライズすることは可能ですか?

たとえば、カスタム TCollection があります。TCollection の子孫で TMemoryStream.WriteComponent() を使用できません。コレクションを TComponent にカプセル化してから、このコンポーネントを作成した場合にのみ機能します。

技術的には問題ありませんが、TCollectionのみを所有する TComponent を宣言するのは少し奇妙に思えます。

Delphi RTL の機能を見逃しているだけでしょうか。TPersistent の子孫は、それ自体を TComponent にカプセル化せずにストリーミングできますか?

TCollection から継承したクラスがあり (「TMyCollection」と呼びます)、そこから新しいクラスを継承する必要があります (「TMyItems」と呼びます)。

通常、TCollection のコンストラクターで ItemClass タイプを渡しますが、私の場合、TMyCollection のコンストラクターは、ItemClass をとらず、所有者のみを取る新しいコンストラクターでオーバーライドされます。

継承されたコンストラクターが ItemClass パラメーターを受け入れない場合、「TMyItems」の ItemClass を変更する方法を知る必要があります。

よろしく。

Date、Time、およびDate/Timeタイプのプロパティを必要とするコンポーネントを作成しています。これらのプロパティをオブジェクトインスペクターに表示し、ポップアッププロパティエディターを使用するオプションを付けたいと思います。

私は公開されたプロパティとして試しTDateましたが、これにより、日付だけで必要な結果が得られます。ただし、同じものが必要ですが、プロパティエディタが付属しTTimeてTDateTimeいません。実際、そこに入力した値も受け入れられません。

TDateTimePropertyプロパティエディタとして使用できるものを見つけたので、とにかく理解しました。このコンポーネントを登録するときに必要な実装を行いました。適用する必要のあるこのプロパティは、実際にはTCollectionItem子孫であり、必ずしもコンポーネントの一部ではなく、コンポーネント内にあります。

これが私がそれを登録する方法です...

これはコンパイルされますが、インストールすると、このプロパティにプロパティエディタがありません。TMyCollectionItem同じ問題の代わりに、コンポーネントのクラス名を使用してみました。

このプロパティエディタを表示するために、ここで何が間違っていますか？

Delphi XE8 と FireDAC を使用して、大規模な SQLite データベースをロードしています。そのために、配列 DML 実行手法を使用して、次のように多数のレコードを一度に効率的に挿入しています。

SQLite データベースへのデータの実際のロードは非常に高速で、その速度に問題はありません。

私を遅くしているのは、繰り返しループですべての値をパラメーターに割り当てるのにかかる時間です。

Params は FireDAC に組み込まれており、TCollection です。ソース コードにアクセスできないため、AsStrings および AsIntegers メソッドが実際に何を行っているかを確認できません。

各挿入の各パラメータに各値を割り当てることは、この TCollection をロードするための非常に効率的な方法ではないように思えます。これをロードするより速い方法はありますか？パラメータのセット全体を一度にロードする方法を考えています。たとえば、(IndiKey、HasData、... FirstAncestralLoop) をすべて 1 つとしてロードします。または、自分の TCollection をできる限り効率的にロードし、TCollection の Assign メソッドを使用して、自分の TCollection を FireDAC の TCollection にコピーすることもできます。

私の質問は、FireDAC が必要とするパラメータのこの TCollection をロードする最速の方法は何でしょうか?

更新: Arnaud のタイミングをいくつか含めています。

Using SQLite with FireDAC で説明されているように(配列 DML セクションを参照):

v 3.7.11 以降、SQLite は複数の値を持つ INSERT コマンドをサポートしています。Params.BindMode = pbByNumber の場合、FireDAC はこの機能を使用して配列 DML を実装します。それ以外の場合、FireDAC は配列 DML をエミュレートします。

配列サイズ (実行ごとにロードするレコード数) を変更して 33,790 レコードの挿入をテストし、pbByName (エミュレーション用) と pbByNumber (複数の値の挿入を使用) の両方でロード時間を計りました。

これはタイミングでした：

これらのタイミングの興味深い点は、これらの 33,790 レコードを TCollection にロードするのに、1 回のテスト実行ごとに 93 ミリ秒かかっていることです。一度に 1 つずつ追加されるか、一度に 10000 ずつ追加されるかは関係ありません。Param の TCollection を埋めるこのオーバーヘッドは常に存在します。

比較のために、pbByNumber のためだけに 198,522 個の挿入でより大きなテストを行いました。

このテストのすべてのケースで、Params の TCollection をロードするオーバーヘッドは約 503 ミリ秒かかります。

したがって、TCollection の読み込みは 1 秒あたり約 400,000 レコードのようです。これは挿入時間のかなりの部分であり、何百万もの大規模なデータベースで作業を開始すると、この追加時間はプログラムのユーザーにとって非常に顕著になります。

これを改善したいのですが、Params の読み込みを高速化する方法をまだ見つけていません。

更新 2: すべてのコードを StartTransaction と Commit の間に配置して、すべてのブロックが一度に処理されるようにすることで、約 10% の時間を短縮できました。

しかし、Params の TCollection をより高速にロードする方法をまだ探しています。

もう1つのアイデア：

うまく機能し、可能であれば最大 16 倍高速になる可能性があるのは、ParamValues メソッドのようなものです。これにより、一度に複数のパラメーターが割り当てられ、バリアント配列を直接提供できるという利点が追加され、値をキャストする必要がなくなります。

次のように機能します。

ただし、ParamValues は、Param の最初のセット、つまり NumIndiParms = 0 にのみ割り当てられます。

ループ内の各インデックス、つまり NumIndiParms のすべてのインスタンスに対してこれを行う方法はありますか?

Bounty: Params の読み込みを高速化したいです。現在、FireDAC に実装されている Params 配列 TCollection の読み込みを高速化する方法を見つけてくれる人に報奨金を提供しています。