0

アドインは最初に backgroundworker を使用せずに作成され、正常に動作しました。同じ ArcMap セッションで実行した直後に追加して表示できるシェープファイルを作成できました。

次に、実行が完了するまで変化を示さなかった進行状況バーを UI に追加しようとしました。そこで、backgroundworker クラスを追加し、時間のかかるシェープファイル作成コードを (変更せずに) backgroundworker の dowork イベント ハンドラーに移動しました。

これにより UI の応答性が大幅に向上しますが、結果のシェープファイルを同じ ArcMap セッションに追加すると、画面に何も表示されません。ArcMap は、「ロックを取得できません [テーブル xxx は別のプロセスによって書き込まれています]。

その時点で書き込みは完了していると思います。また、現在の ArcMap セッションを閉じて新しいセッションを開始すると、問題なく結果を表示できます。

投稿するコードが多すぎて、コードをそのまま backgroundworker クラスに移動したことが問題の原因であると強く感じています。バックグラウンドワーカー/ArcGIS アドインの経験が豊富な皆さんが、何が原因であるかを教えてくれることを願っています。前もって感謝します！

4

1 に答える 1

0

問題を解決しましたが、なぜそうなのかはよくわかりません。

backgroundworkder_DoWork() は、以下の方法で FeatureCursor を使用する関数を呼び出します。

IFeatureCursor featureCursor = FeatureClass.Update(null,true);

カーソルを使用して更新を行う機能を調べます

if (特定の条件) { featureCursor=FeatureClass.Update(null,true); いくつかの追加の更新を行って、機能をもう一度確認します }

最後に featureCursor で Marshal.ReleaseComObject() メソッドを実行しても、シェープファイルへの書き込みロック (".wr.lock") が持続することがわかりました。ただし、featureCursor を再利用する代わりに、"if" 句で新しいカーソルを定義して使用すると、Marshal.ReleaseCombObject() メソッドで書き込みロックを解除できます。ただし、新しいカーソルを定義して使用する場合は、解放メソッドを使用する必要はありません。実行後は「.wr.lock」ファイルが残りますが、出力シェープファイルを同じ ArcMap セッションに追加して問題なく表示できます。

UIスレッドに配置されたときの上記のコードが問題を引き起こさなかったが、backgroundworker_DoWork()によって呼び出されたときにロックの問題が発生した理由について誰かが洞察を与えることができれば幸いです。

また、上記のコードで行ったように FeatureCcursor を再利用するのは悪い習慣ですか?

于 2012-10-03T20:41:17.157 に答える