2013-02-13 10 views
11

.NET (dowolna wersja) działająca pod Windows XP/Vista/7/8 - czy można zarezerwować jeden ekran dla aplikacji pełnoekranowej i wyświetlić dane/grafikę/cokolwiek na tym ekranie przy zachowaniu innych dostępnych ekranów dla systemu Windows Interakcje użytkownika z interfejsem użytkownika, takie jak komputer lub inne aplikacje?Czy można całkowicie przejąć tylko jeden ekran wielu ekranów z .NET w systemie Windows?

Scenariusz Wykorzystanie/zasady tutaj są następujące:

  1. Komputer musi być w stanie uruchomić wszystkie programy jak jest.

  2. Nie jest wymagana interaktywność zawartości .NET (tzn. Brak naciśnięć klawiszy, kliknięć myszy itp.).

  3. Żaden inny interfejs użytkownika ani okna dialogowe z innych aplikacji nie mogą przeniknąć do jednego predefiniowanego ekranu zarezerwowanego do wyświetlania wyników z pliku wykonywalnego .NET.

  4. Wstępnie zdefiniowany ekran z zawartością .NET nie może mieć widocznego kursora myszy, a pozostałe ekrany muszą mieć granice kursora, tak jakby nie było w ogóle żadnego dodatkowego ekranu (tzn. Kursor musi się zatrzymać na krawędziach jednego lub wiele komputerów stacjonarnych).

  5. Zawartość musi być widoczna, nawet jeśli komputer jest zablokowany (tzn. Użytkownik jest zalogowany, ale stacja robocza jest zablokowana w Eksploratorze).

wiem, mogę to osiągnąć z jakiegoś zewnętrznego kontrolera USB, który napędza wtórnego monitora lub innego urządzenia wyświetlającego, a następnie ręcznie zbudować Contents/grafika musi być odłożony do tego interfejsu, ale pytam czy mogę to zrobić z normalnymi sterownikami WDDM z normalnymi monitorami?

Edit: Aby dokładniej wyjaśnić - Rozumiem, istnieje wiele metod, aby osiągnąć nieco podobny wynik, ale tu chodzi o to można spełniać wszystkich specyfikacji/powyższych zasad.

+0

Czy używasz WPF lub Windows Forms? – alu

+3

Po prostu utwórz zmaksymalizowaną najwyższą formę bez obramowania z niestandardowym kursorem, który jest pusty. –

+0

@alu - może użyć jednego lub czegoś innego. Jestem otwarty na wszystkie pomysły tutaj. – allu

Odpowiedz

0

Podejście wybrane zgodnych nieco wszystkich zasad projektowania został ... czekać na niego .. wirtualizacji. Nie jest on jednak zgodny z wymaganiami używania wyłącznie plików wykonywalnych .NET (do włamywania się do WDDM).

Oryginalny komputer to host wirtualizacji z dwoma gośćmi. Jeden dla aplikacji .NET i jeden dla użytkownika końcowego, któremu przypisano odpowiednie USB itp. Takie podejście ma oczywiście wiele zastrzeżeń:

  • WDDM nie jest w żaden sposób wykorzystany i występują problemy z wydajnością. Dla zwykłego zastosowania biurowego nie stanowi to jednak żadnego problemu.
  • O ile nie korzystasz z Hyper-V, oprogramowanie wirtualizacyjne jest zawsze stroną trzecią.
  • Funkcja Hyper-V w Hyper-V nie jest możliwa, więc gość nie może zendalizować niczego więcej (przynajmniej nie z jakąkolwiek rozsądną szybkością, ponieważ byłby uruchomiony bez hiperwizora).
  • W niektórych przypadkach wymagane jest wiele licencji dla dowolnego oprogramowania.
  • Brak IPC lub innej interakcji między plikiem wykonywalnym .NET i innymi aplikacjami między dwoma gośćmi.

Jednak samo rozwiązanie działa idealnie - w żaden sposób użytkownik nie może przesłonić ani interakcji z tym, co jest pokazane na dodatkowym ekranie, o ile podstawowy host jest zasilany i nie ulega awarii. Blokowanie komputera użytkownika końcowego nie ma wpływu na drugiego gościa i tak dalej.

4

To brzmi dla mnie tak, jakbyś projektował aplikację .NET, która będzie używana wyłącznie jako wyjście (np. Do wyświetlania wykresu/wykresu, wideo itp.). Aplikacja musi mieć dedykowany monitor, a żadna inna aplikacja (lub nawet kursor nie może wejść w ograniczenia monitora).

Mam przeczucie, że podczas gdy możesz wymusić aplikację na konkretnym monitorze (XBMC ma tę funkcję), wątpię, czy możesz zapobiec wejściu wszystkich innych aplikacji do regionu wyświetlania monitora.

Kiedy przeczytałem pytanie, coś w mojej głowie kliknęło i pomyślałem "może chcesz czegoś podobnego do koligacji procesora, które możesz ustawić w oknach, i zmusić aplikację do używania tylko konkretnych rdzeni procesora ... może tam jest coś podobnego dla regionów monitorów/wyświetlaczy? "

Rzeczywiście, Windows udostępnia następujące funkcje:

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

Powinieneś móc pinvoke nich bez większych kłopotów. To jednak rozwiąże problem polegający na tym, że możesz wymusić na swojej aplikacji tylko określony monitor. Jak w przypadku każdej innej aplikacji w systemie, wątpię, czy będziesz w stanie łatwo kontrolować swoje powinowactwo wyświetlania.

W przybliżeniu trzeba użyć innego wywołania Win32 API, aby uzyskać odniesienia do wszystkich uchwytów okien w systemie i sprawdzić ich powinowactwo wyświetlania, a jeśli są wyświetlane w dedykowanym monitorze, przenieść je w inne miejsce.

to może pomóc w uzyskaniu wszystkie okna uchwyty:

How to get list or enumerate all handles of unmanaged windows with same class and name

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

Tylko myślałem, że rzucę to tam, to nie może być pomocne, ale miejmy nadzieję, że powinien dać trochę więcej kierunek.

EDIT: Znalazłem to zbyt ... może się przydać

Reserve screen area in Windows 7

+0

Żadne z tych podejść nie przeszkadza w wejściu myszy do ekranu _reserved_ lub nie wyświetla aplikacji nawet wtedy, gdy komputer jest zablokowany. – allu

+0

@allu - Hans już zasugerował rozwiązanie problemu z myszą. Znowu wątpię, byś mógł zmusić mysz do nie wchodzenia w obszar ekranu, ale możesz uniemożliwić jej wyświetlanie w tym regionie, zmieniając kursor na pusty. Podobnie, wątpię, czy możesz zachować widoczność aplikacji, gdy komputer jest zablokowany ... jeśli możesz, chętnie usłyszę, jak! – series0ne

4
  1. Komputer musi być w stanie uruchomić wszystkie programy jak jest.

  2. Nie jest wymagana interaktywność zawartości .NET (tzn. Brak naciśnięć klawiszy, kliknięć myszy itp.).

  3. Żaden inny interfejs użytkownika ani okna dialogowe z innych aplikacji nie mogą przeniknąć do jednego predefiniowanego ekranu zarezerwowanego do wyświetlania wyników z pliku wykonywalnego .NET.

Jednym ze sposobów osiągnięcia tego mogłoby być stworzenie okna dokująca (AppBar). Który miałby podobną funkcjonalność jak stacje dokujące pasku zadań lub pulpicie jak Google Desktop itp

Te dwa artykuły mogłyby być pomocne:
CodeProject: AppBar using C#
CodeProject: Creating an application like Google Desktop in WPF and C#

Innym sposobem rozwiązania nr 3 jest użycie PInvoke (lub jeszcze lepiej, Managed WinAPI), aby skanować komputer w poszukiwaniu otwartych okien w regularnych odstępach czasu. Jeśli okaże się, że okno jest "wkroczeniem", po prostu zaczepiasz go i odsuwasz. Nie jest to najlepsze podejście, ale i tak działa.

4. Wstępnie zdefiniowany ekran z zawartością .NET nie może mieć widocznego kursora myszy, a pozostałe ekrany muszą mieć granice kursora, tak jakby nie było w ogóle żadnego dodatkowego ekranu (tj. Kursor musi zatrzymywać się na krawędziach jednego lub wielu komputerów).

Ustawia właściwość kursora formularza na pusty kursor. To skutecznie usuwa kursor myszy.
Zatrzymanie kursora z dostępu do tej części ekranu jest dość trudne. Najlepiej jest użyć Global Mouse Hooks, aby posłuchać ruchu kursora i zatrzymać ruch kursora na obszarach zajmowanych przez twoje okno. To oczywiście spowodowałoby, że ustawienie właściwości kursora formularza byłoby bezużyteczne, ponieważ i tak kursor nigdy nie jest na formularzu.

5. Treść musi być widoczna, nawet jeśli komputer jest zablokowany (tj.użytkownik jest zalogowany, ale stacja robocza jest zablokowana od Explorer)

ja nie znam żadnego sposobu, aby osiągnąć ten krótki tworzenia aplikacji blokady ekranu, ponieważ standardowe zachowanie systemu Windows jest, aby wyłączyć wszystkie monitory z wyjątkiem pierwotnej jeden.

Edit
Można wyświetlić okno na ekranie blokady, używając psexec.exe -x. PSEXEC jest częścią pakietu SysInternals, dostępnego do pobrania pod numerem http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx.

Jeśli zamierzasz iść tą drogą (wyświetlając formularz na górze ekranu blokady), będziesz potrzebował sposobu na ustalenie, kiedy sesja użytkownika jest blokowana, aby zmienić rozmiar formularza i usunąć go z drogi . W przeciwnym razie musisz znaleźć sposób odblokowania sesji ze swojej aplikacji.

Możesz również chcieć rzucić okiem na to pytanie How to display UI on logon screen in Windows 7, aby zapoznać się z innymi sposobami wdrażania aplikacji na ekranie blokady.

+0

AppBar to świetny pomysł, a ja nagrodzę cię nagrodą za to. – allu

1

Projekt WPF, nad którym pracuję, przeszedł już drogę dodawania wszystkiego w "kontenerze głównym" dziedziczącym po System.Windows.Window, który jest skonfigurowany podczas uruchamiania na podstawie preferencji użytkownika, aby być albo wszystkimi dostępnymi ekranami, okno lub pojedynczy pełny ekran. Że kontrola a potem po prostu ustawia się w zależności od preferencji, co następuje:

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; 
    } 
+0

inaczej dobry pomysł, ale nie zapobiega wtargnięciu myszy, nie pozostaje widoczny, gdy komputer jest zablokowany i tak dalej. – allu

Powiązane problemy