4

Delphi 2007 プロジェクトで一連の「EClassNotFound」エラーが連鎖的に発生しています。よくあるケースのように、Name プロパティ値の欠落が原因ではないようです。また、初期化セクションに RegisterClass(XXX) を追加すると、EClassNotFound エラーがすぐに修正されますが、別のエラーが一見無期限に続きます。

最後に、テキスト エディターで DFM ファイルをクラックして開きましたが、破損しているように見えます (フォーム要素名に非 ASCII 文字が多数含まれており、DFM ファイルで見慣れていたものと比較すると、非常に「構造化されていない」ように見えます)。 ）。（私はここに同じことを投稿しますが、非aSCIIで問題ないかどうかわからないので、延期します）。

フォームは正常にロードされ、コンパイル/構文チェックもOKのようですが、実行すると問題が発生します。

SVN の初期バージョンに戻ると、しばらくの間この状態にあるように見えます。そのため、A) DFM ファイルが問題ではないか、B) Delphi フォーム ストリーミングに問題があるかのいずれかだと思います。 -寛容/堅牢 (ボーナス質問: どちらですか?).

DFM ファイルに問題があり、破損している場合、ロールバックはロールバック WAY である必要があり、コストが高くなります。IDE がまだファイルをロードできることを考えると、ファイルをクリーンアップできるユーティリティはありますか?

それとも、DFM が主な容疑者であるということで、私は完全に基地から外れているのでしょうか?

ご意見をお寄せいただきありがとうございます。DFM ファイルのバイナリ/テキスト オプションを忘れていたので、役に立ちました。DFM 自体は破損していないようです。

ただし、まだ EClassError の問題があります。re: プロパティ値が欠落している、または存在しないプロパティを参照しているなど、さらなる質問: エラーが発生したクラスは (現在は TnxSqlUpdateObject ですが、これまでの経験が一貫している場合はおそらくもっと待っています) 通常/常に実際の「犯人」クラス/オブジェクトですか?

たとえば、現在、私のメイン フォームには TnxSqlUpdateObject への 4 つの参照があり、それらは実際にフォームにドロップされています。RegisterClass(TnxSqlUpdateObject) を初期化セクションに配置すると、その EClassNotFound エラーに対しては問題なく実行されますが、次のエラー (この場合は TStringField) に進みます。

この場合、NexusDB コンポーネントを再インストールし、問題と思われるコンポーネントのいくつかを使用して新しいプロジェクトを構築しました。実際のプロジェクトからこの他のフォームを追加するまで、コンパイルして正常に実行されます（残念ながら、他の多くのフォームを参照しています）。

SO、私の本当の問題は、すべての EClassNotFound エラーを体系的に診断して修正する方法のように思えますか?

4

6 に答える 6

15

コンポーネントがフォーム上にあるが、ソース ファイルのフォーム定義にもエントリがない場合、このエラーが発生します。ほとんどの場合、別のフォームからコピーして貼り付けたときに発生します。最も簡単な解決策は、コンポーネントを選択し、切り取ってから貼り付けることです。保存すると、コンポーネントのユニットがソースに追加され、再度実行するとすべて問題ありません。

于 2009-01-27T13:26:33.487 に答える
2

Delphi IDEでフォームをロードできる場合、DFMリソースは破損していません。Delphiは、最終的な実行可能ファイルが使用するのと同じコードを使用してDFMをロードするため、それが理由ではないと思います。

Delphi IDEでDFMを直接開くか（対応するpasファイルが開いていない場合）、Alt+F12を使用してDFMのフォームビューとテキストビューを切り替えることができます。このビューでは、構造は正常で、正しいインデントなどが必要です。

Gamecatが指摘したように、フォームポップアップメニューのコマンドを使用して、DFMストレージ形式を切り替えることができます。Delphi 5+のテキストのままにしておくと、SVNでこのようにうまく機能します。

ランタイムの問題の原因については-私にはわかりません...

編集：問題の原因としてDFMを除外した後、使用リストの重要なユニットが欠落していると推測できます。これは、フォームのすべてのコンポーネントに対応するメンバーフィールドがない場合にのみ発生する可能性があります。コードでコンポーネントにアクセスしない場合でも、DFMで参照されているすべてのコンポーネントもフォームに含まれていることを確認する必要があります。これにより、ファイルが保存されるときに、Delphiは不足している単位をuses句に追加します。フォームクラスにDFM内のすべてのコンポーネントへの参照がある場合は、コンポーネントを手動で登録する必要はありません。

簡単に確認するには、テストフォームを作成し、「問題のある」フォームに含まれるすべてのコンポーネントをドロップして（1つのインスタンスで十分です）、これが機能するかどうかを確認します。

于 2009-01-27T11:37:57.903 に答える
2

dfm ファイルは、バイナリまたは tekst である可能性があります (バージョン 4.0 から正しいので)。

これは、フォームを右クリックして、テキスト DFM フラグを確認することで確認できます。

dfm ファイルが破損している場合、tou は疑わしい行をすべて削除して修復を試みることができます。object .. end セットはそのままにしておくようにしてください。おそらくいくつかのプロパティ値が失われるだけです。

ところで、dfm ファイルは次のようになります (一般的な構造を把握するため)。

object Form5: TForm5
  Left = 0
  DesignSize = (
    426
    652)
  object Button1: TButton
    Left = 343
  end
  object Memo2: TMemo
    Anchors = [akLeft, akTop, akRight, akBottom]
  end
end

そうでない場合は、バイナリ ファイルを編集している可能性があります。

于 2009-01-27T11:20:50.090 に答える
2

動作する最近コンパイルされた exe がある場合は、PE Explorerなどのリソース エディターを使用して dfm-definition を取得できます。次に、exeからのものと現在のものを比較できます。

バイナリ dfm ファイルをテキスト ファイルに変換するツールもあると思います。これにより、ファイルが見やすくなり、本当に破損しているかどうかを判断するのに役立ちます。フェリックスがこの話題について何かを持っているようです。

Delphi IDE がエラーなしでフォームを正常に表示する場合、破損エラーがあるとは信じられません。パッケージに問題がある可能性はありますか？ランタイムパッケージを使用していますか?

アップデート：

callstack と memorydumt でより詳細なエラー メッセージを取得するために、Eurekalog や madExcept などを試してみましたか? 多分それはあなたに問題についての手がかりを与えるでしょう.

しかし、一般的に、このエラーは実行時パッケージが見つからないか、uses-clause にユニットが見つからないことが原因だと思います。ウィッチ コンポーネントがエラーの原因であることがわかっている場合は、ソースで RegisterClass( ) の呼び出しを検索し、そのユニットが何らかの形でプロジェクトの uses-clause に含まれているかどうかを確認します。そうでない場合は、追加してからやり直してください。

于 2009-01-27T13:47:48.233 に答える
1

これを試して：

  1. 最初にバックアップを作成する
  2. デザイナーでフォームを右クリックします。「テキスト DFM」のチェックを外す
  3. 保存
  4. デザイナーでフォームを右クリックします。「テキスト DFM」にチェックを入れる
  5. 保存
于 2009-01-27T17:53:11.030 に答える
1

これは、カスタム コンポーネントの 1 つを変更し、そこからプロパティを削除した場合に発生する可能性があります。プロパティは DFM にまだあり、Delphi はそれを初期化しようとします。

問題の原因となっているコンポーネントを特定できるように、DFM から手動でパーツを削除してみてください。

于 2009-01-27T12:20:28.847 に答える