4

フォームエディターコンポーネントのプレビューペインとして使用するために、変更されたEclipse（Indigo）のビューにorg.eclipse.swt.browser.Browserを埋め込みます。フォームモデルの変更または要素の選択の変更では、コードはvaadin 6を介してフォームをレンダリングし、ブラウザコンポーネントに表示します。

さて、これはほとんどの場合魅力のように機能します。ただし、非常に複雑なフォームの場合、vaadinによって生成されたHTML + JSはブラウザーに多くのストレスを発生させ、最大数秒間応答しなくなります。それ自体は悲劇的なことではありませんが（1）、SWTブラウザコンポーネントがそのようなもののレンダリングでビジー状態である限り、EclipseUIスレッド全体がブロックされます。

これを再現する簡単な方法は、javascript関数内でブロックするHTMLページを作成し（例についてはhttps://gist.github.com/creinig/5150747を参照）、SWTブラウザーに表示することです。そのJS機能が実行されている限り、SWTアプリケーション全体は何にも応答しません。

この問題について私が見つけた唯一の情報は

あまり役に立たなかった:(

ブラウザコンポーネントのAPIドキュメントは、そのレンダリングがUIスレッドによって定期的にトリガーされるのか、それ自体がUIをブロックする何かをトリガーするのかについての洞察を提供していないようです。

ブラウザコンポーネントのレンダリングをSWTUIスレッドから切り離す方法はありますか？または、ブラウザに何かがぶら下がるのを防ぐためにEclipse UIを保護するためにできることは他にありますか？

（1）：この複雑さのレベルのフォームが必要です。レンダリングパフォーマンスはすでに最適化されており、vaadin7に切り替えると速度も向上する可能性があります。しかし、重大度が低下した場合に限り、問題は確実に持続します。

4

1 に答える 1

0

実際の解決策ではありませんが、Works For Me（TM）の回避策：ここで説明するように、SWTからシステムのデフォルトブラウザを起動するのは非常に簡単です。そこで、ブラウザコントロールを無効にして、代わりにシステムブラウザを開くことで、ビューを「デタッチ」するオプションをブラウザコントロールを含むビューに追加します。

リンク先のページがネットから外れた場合の要点は次のとおりです。

org.eclipse.swt.program.Program.launch("http://my.funny.url/");

HTTPURL用に登録されたアプリケーションを起動します。言い換えると、システムのデフォルトブラウザです。幸せが続く:)

于 2013-03-13T14:12:22.677 に答える