2

ダイアログでのユーザー入力の検証が失敗したときに呼び出すユーティリティルーチンがあります。問題のあるコントロールにフォーカスを設定し、ビープ音を鳴らして、ユーザーに適切なメッセージを表示します。これは、問題のあるコントロールが非表示になっていない限り、うまく機能します。ここで、関連するコントロールがある種の折りたたみ可能なグループボックス（場合によってはネストされている）の子である状況にこれを適応させる必要があり、SetFocusを呼び出す前に「祖先」ボックスが展開されていることを確認する必要があります。

今、私にはいくつかの可能性があります：

  • 折りたたみ可能なコンポーネントに関する知識をエラー報告ルーチンに組み込みます。ルーチンはむしろ一般的なままでなければならないので、私はそれを避けたいと思います。
  • SetFocusの前（または代わりに）に呼び出すことができるコールバックを渡します。関連するすべての場所でコールバックを渡すことを忘れないようにする必要があるため、これはエラーが発生しやすくなります。
  • 私のお気に入りの解決策は、おそらくコンテナコントロールに「あなたとあなたの子コントロールが表示されていることを確認してください」というイベント（またはオーバーライド可能なメソッド）（おそらくTWinControl）ですが、そのようなことはわかりません。

この状況にどのように対処できるかについてのアイデアはありますか？

4

3 に答える 3

4
  1. 次のようなメソッドを使用してインターフェイスを定義しますEnsureVisible。
  2. すべてのコンポーネントに実装します（これらのコンポーネントの一部の独自のバージョンを派生させる必要がある場合があります）。これにより、異なるコントロールがまったく異なる動作をすることができます。
  3. コントロールが表示されていることを確認する必要がある場合、コントロールはその親をウォークしEnsureVisible、インターフェイスが実装されている場合は呼び出します。

インターフェイスが気に入らない場合は、カスタムWindowsメッセージを使用してください。ただし、基本的な考え方は理解できます。

于 2011-02-10T15:57:27.230 に答える
2

私の意見では、最良の解決策は、すべてのコンテナーコントロールに関する知識を構築する別個のルーチンであり、ダイアログ検証ルーチンを一般的なものに保ち、同時に、簡単にテストおよび保守できるように十分に焦点を絞ることができます。次のようなもの：

procedure ForceControlVisible(C: TControl);
begin
  // Recursive code
  if Assigned(C.Parent) then ForceControlVisible(C.Parent);
  // Code specific to each container control class
  if C is TTabSheet then
     begin
       // Code that makes sure "C" is the active page in the PageControl
       // goes here. We already know the PageControl itself is visible because
       // of the recursive call.
     end
  else if C is TYourCollapsibleBox then
     begin
       // Code that handles your specific collapsible boxes goes here
     end      
end;

仮想メソッドまたはインターフェースの実装に依存するOOPスタイルのメソッドは、はるかに洗練されていますが、使用するすべてのコントロールのソースコードにアクセスする必要があります。必要なすべてのソースにアクセスできる場合でも、導入しないことが望ましいです。これらのコントロールのアップグレードが困難になるため、変更を加えます（サプライヤから新しいファイルを取得した後、変更を再導入する必要があります）。

于 2011-02-10T15:39:36.993 に答える
1

各コンポーネントはそのを知っていParentます。リストを上に移動して、各親を表示できます。

于 2011-02-10T15:40:28.513 に答える