2011-10-05 3 views
7

私は自分自身をTextEditorX extends TextEditorと定義しました。典型的なEclipseベースのRCPシナリオ(標準プラグイン、プロジェクト・エクスプローラー/ Navigatorで作業台)で、誰かが(プロジェクト・エクスプローラーまたはナビゲーターを経由して)いくつかのエディタが開かれたファイルの名前を変更しようとする動作は次のとおりです。汚れたEditorPartは、Eclipseのリソース名の変更をどのように禁止しますか?

  • の場合エディタがdirtyでない場合は、名前の変更が許可されます。その後、新しいファイル名を引数としてeditor.setInput()が呼び出されます。

  • はそれがdirtyだ場合は、エラーがスローされます(doc.txtが保存されていないです「は、「リソースの名前を変更」:」見つかった問題「リファクタリングを実行中に致命的なエラーが発生しました」)。

私の質問は:

  • どのレベルでは、この動作は定義されていますか?私は、パッケージorg.eclipse.ltk.ui.refactoring.resourceが関わっていると思います...しかし、たとえば、エディタが汚れていない場合でも名前の変更を禁止したいとします。この動作は、エディタ(またはドキュメントプロバイダ)の一部のメソッドによって判断できますか。私はいくつかコード化/拡張する必要がありますRenameParticipant

  • doc.txtリソースがそのエディタインスタンスによって開かれていることをどのようにリマーマーが知っていますか?開いているすべてのエディタをチェックし、それぞれにeditorInputを尋ねるか、documentProvidersが関係していますか?具体的には、「メイン」ファイルの他に、他のリソース(マルチファイル入力)に依存する特定のエディタがあり、入力の名前を変更する前にリネマが彼に尋ねるようにしたいとします。このシナリオにはどのようにアプローチしますか?

+0

ここではソースコードがないので、最初の質問では、isDirty()をオーバーライドしてエディタでtrueを返すと考えたことがありますか?実際に変更されているかどうかを調べる必要がある場合は、 'super.isDirty()'を使用することができます。 –

+0

エディタのタブのアスタリスクは、この "ダーティ"という小さなものではないでしょうか?決して逃げない?これにより、ユーザーは頭を傷つける可能性があります。 – stracka

答えて

0

変更されたファイルの名前の変更を防ぐための理論的な理由はありません。そのために、エディタはWorkspaceにResourceChangeListenerを登録し、MOVE通知に応答してIEditorInputを更新するだけです。それは良い答えですが、おそらく良いアプローチであるかどうかは分かりません。

関連する問題