Witam,
Używam środowiska netbeans, tworzę aplikację Desktop application(Swing).
Tworzę małe okienko w którym wyświetlam np. aktualną godzinę.
Czy jest jakaś właściwość okna aby było ono zawsze "na wierzchu" ? Chciałbym aby moje okienko było zawsze widoczne w tym samym miejscu niezależnie od tego jaka aplikacja się w tle uruchomi.
Pozdrawiam.
setAlwaysOnTop(true)
A istnieje jakaś mocniejsza metoda? Ponieważ chciałbym zrobić aplikację, która będzie działała w grze i będzie widoczna w grze, jednak setAlwaysOnTop(true); działa na okienkowe aplikacje, a w grach, które zasłaniają cały ekran nie wyjdzie na wierzch. Może istnieje jakiś systemowy sposób układania aplikacji, która jest wyżej ustawiona nad którą?
Oczekujesz cudów. To nawet w C czy asemblerze ciężko zrobić bo trzeba odwoływać się bezpośrednio do bufora ekranu w danym trybie graficznym i nie rzadziej niż aktualizacja takiego ekranu przez grę zamazywać jego kawałek swoją grafiką zegarka (inaczej będzie migać). Musisz więc dowiedzieć się gdzie jest ramka bufora, jaki jest plan graficzny, i jak często jest aktualizowany przez aplikację fullscreen. Kupa roboty bez gwarancji pełnego powodzenia.
A nie prościej byłoby uruchomić tą grę w trybie windowed?
Najprościej będzie mamalować kropkę na środku ekranu, bo zapewne chodzi o "celownik" w jakimś FPSie...
:D Nie chodzi mi o fps'y tylko aplikację, dzięki której można się bardziej zsynchronizować z grą. Poczytałem trochę o tym i wiem, że aplikacje full screenowe są na "najwyższym poziomie", na którym może być tylko jedna aplikacja. Jest to do zrobienia, ale nie ma nigdzie podanej konkretnej metody. Dodatkowo czytałem gdzieś, że jeśli nałożylibyśmy coś takiego na full screena to moglibyśmy zakłócić jego layout, przez co gra mogłaby się crashować, bugować itp. Nawet komunikaty od skype, albo gg przebijają się przez grę i co więcej można na nie kliknąć, ale często mrugają i minimalizują grę.
Jest to teoretycznie do zrobienia i są programy, które tak działają, ale jest to trudne i wymaga mnóstwa testów. Taki program może okazać się nieprzenośny nie tylko między różnymi systemami (co jest prawie pewne), ale w skrajnym wypadku nawet między różnymi wersjami Windows w ramach tego samego systemu. Chodzi o to, że od dekady w trybach graficznych nie ma żadnego standardu. Sterownik graficzny podaje systemowi listę obsługiwanych rozdzielczości i planów. Listę tę ma system i może ona okazać się częściowo niedostępna dla aplikacji trzecich. Aplikacje pełnoekranowe negocjują plan graficzny w jakim będą pracować uzgadniając te obsługiwane przez siebie z trybami podawanymi w odpowiedzi przez system. Obca aplikacja nie ma wglądu do tej komunikacji, więc może się zdarzyć, że aplikacja pełnoekranowa wynegocjuje z systemem (a de facto z kartą graficzną) plan, który będzie nieznany i niezrozumiały dla Twojej aplikacji.
Dlatego ta Twoja musiałaby mieć jak największą bazę rozpoznawanych przez siebie trybów graficznych i każdy powinna obsłużyć. Część gier wypełnia bufor grafiki bez pośrednictwa systemu (nawet bibliotek DirectX, choć to coraz rzadsze), posługują się przełączaniem buforów graficznych umiejscowionych w swojej prywatnej pamięci, potrójnym buforowaniem i różnymi strategiami dotyczącymi synchronizacji tych buforów z wyświetlaniem ich na monitorze. Twoja aplikacja musiałaby to wszystko rozpoznać, dostosować się i jeszcze uzyskać dostęp do pamięci, do której bronić dostępu może sam procesor (np. inny ring zabezpieczeń).
Jest to zadanie trudniejsze niż Ci się wydaje. Jeżeli sądzisz, że uda Ci się mazać po ekranie w grze, którego zrzutu nie potrafią zrobić (a bywają takie gry) nawet najlepsze służące do tego aplikacje (a one tylko czytają pamięć), to dość wysoko mierzysz.
Tak czy inaczej nie jest to zadanie do zrobienia w całości w Javie.
Tradycyjnie robi się to poprzez hooki na funkcje DirectX oraz OpenGL, a nie jakieś przechwytywanie bufora ekranu ;). Metoda ta załatwia 99% gier. W Javie oczywiście tego nie zrobisz, ale w C/C++ już tak i sam sposób hookowania nie będzie przenośny, ale resztę kodu możesz współdzielić pomiędzy platformami.
Na szczęście było wspomniane o trybie okienkowym. Bardzo za to dziękuję, ponieważ się przydało. Jest to bardzo dobre rozwiązanie, które wymagało niewielkiego wkładu pracy, a całkowicie mnie satysfakcjonuje. Olamagato podziwiam twoją wiedzę.
A czy jest coś podobnego w Windows Forms C#?
@bzderek: Na pewno w C# jest dostępne wszystko co jest dostępne w C++ pod Windows ponieważ .NET ma dostęp do wszystkich funkcji systemowych Windows. Również tych niskopoziomowych. Natomiast jakieś ograniczenia wykorzystania konkretnego API może wprowadzać samo środowisko, którego używasz do klecenia. Większość środowisk pod Windozę umożliwia odwołanie się do API w C/C++, w których są wywołania zwrotne (wcześniej ich rolę pełniły przerwania softwarowe).
Już wiem!
Należy umieścić taki kod w właściwości Form.Load:
this.TopMost = true;
albo w formularzu nastawić właściwość TopMost na true