12

Windows XP/Vista/7/8 で実行されている .NET (任意のバージョン) では、フルスクリーン アプリケーション用に 1 つの画面を確保し、その上にデータ/グラフィックスなどを表示しながら、Windows UI ユーザーが他の画面を利用できるようにすることは可能ですか?デスクトップや他のアプリなどの相互作用?

ここでの使用シナリオ/ルールは次のとおりです。

  1. PC は、すべてのプログラムをそのまま実行できる必要があります。

  2. .NET コンテンツに対話性は必要ありません (つまり、キーを押したり、マウスをクリックしたりする必要はありません)。

  3. 他のアプリケーションの他の UI やダイアログは、.NET 実行可能ファイルからの出力を表示するために予約された 1 つの定義済み画面に侵入することはできません。

  4. .NET コンテンツを含む事前定義された画面にはマウス カーソルが表示されてはならず、他の画面には余分な画面がまったくないかのようにカーソル境界が必要です (つまり、カーソルは 1 つまたは複数のデスクトップの端で停止する必要があります)。

  5. PC がロックされていても (つまり、ユーザーはログインしているが、ワークステーションは Explorer からロックされている)、コンテンツが表示されている必要があります。

セカンダリ モニターまたはその他のディスプレイ デバイスを駆動する外部 USB コントローラーを使用してこれを実現し、このインターフェイスにプッシュするコンテンツ/グラフィックスを手動で作成できることはわかっていますが、通常の WDDM ドライバーを使用してこれを行うことができるかどうか尋ねています。通常のモニター?

編集:さらに明確にするために-多少似た結果を達成するための複数のアプローチがあることは理解していますが、ここでの問題は、上記のすべての仕様/ルールに準拠できるかどうかです。

4

4 に答える 4

4
  1. PC は、すべてのプログラムをそのまま実行できる必要があります。

  2. .NET コンテンツに対話性は必要ありません (つまり、キーを押したり、マウスをクリックしたりする必要はありません)。

  3. 他のアプリケーションの他の UI やダイアログは、.NET 実行可能ファイルからの出力を表示するために予約された 1 つの定義済み画面に侵入することはできません。

これを実現する 1 つの方法は、ドッキング ウィンドウ (AppBar) を作成することです。これには、タスクバーや Google デスクトップなどのデスクトップ ドックと同様の機能があります。

次の 2 つの記事が役に立ちます:
CodeProject: AppBar using C#
CodeProject: Making an application like Google Desktop in WPF and C#

#3 に対処するもう 1 つの方法は、PInvoke (またはより適切なManaged WinAPI ) を使用して、開いているウィンドウがないか定期的にコンピューターをスキャンすることです。ウィンドウが「不法侵入」していることが判明した場合は、それにフックして移動します。最善のアプローチではありませんが、とにかく機能します。

4 . .NET コンテンツを含む事前定義された画面にはマウス カーソルが表示されてはならず、他の画面には余分な画面がまったくないかのようにカーソル境界が必要です (つまり、カーソルは 1 つまたは複数のデスクトップの端で停止する必要があります)。

フォームのカーソル プロパティを空のカーソルに設定します。これにより、マウスカーソルが効果的に削除されます。
カーソルが画面のその部分にアクセスするのを止めるのは非常に注意が必要です。私の最善の策は、Global Mouse Hooksを使用してカーソルの動きをリッスンし、カーソルがウィンドウによって占められている領域に移動するのを止めることです。とにかくカーソルがフォーム上にないため、フォームのカーソルプロパティの設定は明らかに役に立たなくなります。

5. PC がロックされている場合でも、コンテンツが表示される必要があります (つまり、ユーザーはログインしているが、ワークステーションはエクスプローラーからロックされています)。

Windows の標準的な動作は、プライマリ モニター以外のすべてのモニターをオフにすることであるため、ロック スクリーン アプリケーションを作成する以外に、これを実現する方法がわかりません。

編集
でロック画面にウィンドウを表示できますpsexec.exe -xhttp://technet.microsoft.com/en-us/sysinternals/bb897553.aspxPSEXECからダウンロードできる SysInternals スイートの一部です。

この方法 (ロック画面の上にフォームを表示する) を行う場合は、フォームのサイズを変更して邪魔にならないように、ユーザー セッションがロックされているタイミングを判断する方法が必要です。それ以外の場合は、アプリからセッションのロックを解除する方法を見つける必要があります。

ロック画面アプリを実装する他の方法については、Windows 7 のログオン画面に UI を表示する方法に関するこの質問もご覧ください。

于 2013-02-19T11:56:46.203 に答える
4

純粋に出力 (つまり、グラフ/チャート、ビデオなどを表示する) に使用される .NET アプリケーションを設計しているように思えます。アプリケーションには専用のモニターが必要であり、他のアプリケーションは使用できません (または、カーソルでさえモニターの境界に入ってはなりません)。

私の直感では、アプリケーションを特定のモニターに強制することはできますが (XBMC にはこの機能があります)、他のすべてのアプリケーションがモニターの表示領域に入るのを防ぐことはできないと思います。

質問を読んだとき、頭の中で何かがクリックされ、「おそらく、Windowsで設定できるCPUアフィニティに似たものが必要であり、アプリケーションに特定のCPUコアのみを使用させる...おそらく似たようなものがあると思いましたモニター/表示領域?」

案の定、Windows は次の機能を提供します。

http://msdn.microsoft.com/en-gb/library/windows/desktop/dd375340(v=vs.85).aspx

http://msdn.microsoft.com/en-gb/library/windows/desktop/dd375338(v=vs.85).aspx

これらは問題なくピンボークできるはずです。ただし、それは、アプリケーションを特定のモニターのみに強制できるという問題を解決するだけです。システム内の他のすべてのアプリケーションに関しては、ディスプレイ アフィニティを簡単に制御できるとは思えません。

大まかに推測すると、別の Win32 API 呼び出しを使用して、システム内のすべてのウィンドウ ハンドルへの参照を取得し、それらの表示アフィニティを確認し、それらが専用モニターに表示されている場合は別の場所に移動する必要があります。

これは、すべてのウィンドウ ハンドルを取得するのに役立つ場合があります。

同じクラスと名前を持つアンマネージ ウィンドウのすべてのハンドルを一覧表示または列挙する方法

http://msdn.microsoft.com/en-us/library/ms633497%28VS.85%29.aspx

役に立たないかもしれませんが、うまくいけば、それがあなたにもう少し方向性を与えるはずです。

編集:私もこれを見つけました...何か役に立つかもしれません

Windows 7 で画面領域を確保する

于 2013-02-19T10:53:59.557 に答える
1

私が取り組んでいる WPF プロジェクトは、ユーザー設定に基づいて起動時に設定された System.Windows.Window から継承する「マスター コンテナー」内にすべてを追加して、利用可能なすべての画面、ウィンドウ、またはシングルフルスクリーン。そのコントロールは、次のように設定に基づいて設定されます。

    private void SpanAllMonitors()
    {
        WindowStyle = WindowStyle.None;
        ResizeMode = ResizeMode.NoResize;
        Width = SystemParameters.VirtualScreenWidth;
        Height = SystemParameters.VirtualScreenHeight;
        Left = SystemParameters.VirtualScreenLeft;
        Top = SystemParameters.VirtualScreenTop;
    }

    private void SingleScreen()
    {
        WindowStyle = WindowStyle.None;
        ResizeMode = ResizeMode.NoResize;
        Width = SystemParameters.PrimaryScreenWidth;
        Height = SystemParameters.PrimaryScreenHeight;
        // this will take over the 'primary' monitor, additional math
        // should allow you to place it on a secondary or other monitor
        Left = 0;
        Top = 0;
    }
于 2013-02-25T16:52:08.233 に答える
0

ある程度すべての設計ルールに準拠するために選択されたアプローチは、...ちょっと待って..仮想化でした。ただし、(WDDM にハッキングするために) .NET 実行可能ファイルのみを使用するという要件には準拠していません。

元の PC は、2 つのゲストを持つ仮想化ホストです。1 つは .NET アプリケーション用、もう 1 つは適切な USB などが割り当てられたエンド ユーザー用です。このアプローチには当然、多くの注意事項があります。

  • WDDM はまったく活用されておらず、パフォーマンスの問題が発生する可能性があります。ただし、カジュアルなオフィス アプリケーションの場合、これはまったく問題になりません。
  • Hyper-V を使用しない限り、仮想化ソフトウェアは常にサードパーティです。
  • Hyper-V 内で Hyper-V を使用することはできないため、ゲストはそれ以上何も仮想化できません (少なくとも、ハイパーバイザーなしで実行されるため、妥当な速度ではありません)。
  • 場合によっては、ソフトウェアの複数のライセンスが必要になります。
  • 2 つのゲスト間で、.NET 実行可能ファイルと他のアプリとの間で IPC やその他の相互作用はありません。

ただし、ソリューション自体は完全に機能します。基盤となるホストに電源が供給されていて、それ自体がクラッシュしない限り、ユーザーが追加の画面に表示されているものを上書きしたり操作したりすることはできません。エンド ユーザーの PC をロックしても、他のゲストなどには影響しません。

于 2013-02-26T07:18:07.047 に答える