TreeNode.EndEdit
と 設定はどう違いますNodeLabelEditEventArgs.CancelEdit
か?
1 に答える
表面的には、呼び出しは実際、AfterLabelEditまたはBeforeLabelEditイベントハンドラーでEndEdit(true)
発行するのと同じことを行うように見えます。ただし、2つのアプローチは同等ではなく、同じ目的で使用されることはありません。e.CancelEdit = true
実際の動作例で示すのが最適です。
彼らは同じことをします、なぜなら:
- を呼び出す
EndEdit(true)
と、ツリーノードは編集モードを終了し、変更を破棄します。 e.CancelEdit = true
中に発行AfterLabelEdit
すると、ツリーノードは編集モードを終了し、変更を破棄します。
しかし、それらは同等ではありません。理由は次のとおりです。
- を呼び出さない場合
EndEdit(true)
、ツリーノードの編集モードは(明らかに)変更されません。 - 中に発行しない場合でも、ツリーノードは編集モードを終了します(そして変更をコミットします)。
e.CancelEdit = true
AfterLabelEdit
- 中に発行しない場合でも、ツリーノードは編集モードに入ります。
e.CancelEdit = true
BeforeLabelEdit
もう1つの違いは、をEndEdit()
トリガーしますがAfterLabelEdit
、AfterLabelEdit
それ自体を再帰的にトリガーしないことです(幸いなことに)。
現在、通常、NodeLabelEditEventArgs.CancelEditは検証に使用されます。つまり、ツリーノードラベルへの無効な変更を破棄するか(中AfterLabelEdit
)、またはユーザーが一部のノードのラベルを編集できないようにします(中BeforeLabelEdit
)。どちらの場合も、ユーザーはラベルの編集をすでに終了しているか、まだ開始していません。
EndEdit()は、ユーザーがまだラベルを編集している間に、編集を強制的にコミットまたはキャンセルするために使用されることになっています。もちろん、それEndEdit(false)
は悪で間違っていることを意味します。なぜなら、ユーザーが入力を完了する前に、彼の同意なしに、潜在的に破壊的な変更をコミットするからです。だから、実際にそのように呼ばれるのを見たことがありません。
現在の編集を破棄するために呼び出すと、他のEndEdit(true)
何かが今絶対にフォーカスを必要とし、ツリーノードがフォーカスを失ったときに不完全な編集を自動コミットしたくない場合に役立つことがあります。ただし、そのようにユーザーの作業を破棄することは、依然として失礼です。
MFCの時代には、EndEdit(true)
同等の正当な使用法がありました。ユーザーがキーを押したときに編集をキャンセルすることESC
です。信じられないかもしれませんが、その機能は当時MFCですぐにサポートされていませんでした(そしておそらく今日はまだサポートされていないので、私はチェックしませんでした)。
EndEdit()
しかし、最近では、私の意見ではあまり使用されていません。安心して休ませたほうがいいです。