3

私たちの MOSS '07 サイトには、別のサーバー上のサイトを指すページ ビューアー Web パーツだけを含むページがあります。ただし、そのページ (およびページ ビューアー Web パーツがある他のページ) では、ドロップ ダウン メニューとホバー効果が非常に遅く、訪問者のコンピューターの CPU を完全に使い果たしていることに気付きました (プロセスはIExplorerです)。

テストを通じて、Web パーツがどの URL を指しているかは問題ではないと判断できました...ページに Iframe があるだけで、それが発生するようです (Google のホームページを読み込むようにビューアーを設定するだけです。これはおそらく私が知っている最も単純なサイト--それでも問題が発生します)。Web パーツを削除すると、メニューは正常に機能し始めます。

デバッガーをプロセスにアタッチし、関数をステップ実行して呼び出しましたが、関数でゼロMenu_HoverStaticに割り当てるときに苦労しているようです。panel.scrollTopPopOut_Show

他の誰かがこれに気づきましたか？...おそらくそれに対する解決策を見つけましたか？私たちのサーバーで関数を編集する場所が見つかりませんPopOut_Show(.NET DLL の 1 つのリソースだと思います) または、とにかく本当に重要ではないと思うので、その行をコメントアウトします... at少なくとも当サイトでは。

私たちの SharePoint サイトでホストされている別のサーバーからの Web ページを持つ機能は本当に気に入っていますが、ホバー時のパフォーマンスは苦痛であり、正直なところ、受け入れられません。ユーザーのコンピューターのリソースによっては、ホバー効果が完了するまでに 15 秒かかることがあります!!!!

どんな提案でも大歓迎です！

4

2 に答える 2

0

お返事ありがとうございます。私は実際に問題が何であるかを発見することができました (私が行ったときに、ここで共有できなかったことをお詫びします!)

問題は、ページに IFRAME があることによるものではなく、ゾーンを幅と高さ 100% に設定したためです。しかし、IE では、ドロップダウンの場所を計算しようとするとエラーが発生しました (どの JavaScript 関数または呼び出しが正確に原因だったかは覚えていませんが、デバッガーでステップスルーしたことは覚えています)。 「ロケーションオフセット」などで行います。当時の私の見解は、ドロップダウン メニューを画面上に配置しようとしていて、配置の計算に失敗していたというものでした。

これを回避するには、ページが読み込まれた後にゾーンの高さをプログラムで設定する JavaScript ルーチンを設定する必要がありました。高さを正確に設定することで、メニューのドロップダウンの問題が防止されました。もちろん、これは理想的ではありませんでした。ユーザーがウィンドウのサイズを変更しても、IFRAME (より正確にはウィンドウが含まれるゾーン) のサイズが変更されないからです。しかし、それは問題に適したバンドエイドでした。

IE 8 がリリースされたときにこれが修正されることを願っています。

于 2009-02-13T17:01:00.107 に答える
0

SharePoint の組み込み JavaScript は、ページ ビューアー Web パーツ内の IFrame が完全に読み込まれるまで、ブラウザーを待機させている可能性があります。ページをクリックしようとすると、「スクリプトが読み込まれるまでお待ちください...」というステータス バー メッセージが表示される場合は、間違いなく問題です。

于 2008-12-09T19:24:12.397 に答える