Zapewniam jednak że stanowcza większość przypadków to wywoływanie programu bez przekierowań strumienia wyjścia poza konsolę.
takim tokiem rozumowania nie powinno sie obslugiwac bledow, gdyz wiecej razy funkcja fykona sie prawidlowo. Przekierowanie io jest udokumentowana metoda, jest to mala czesc dzialania OS, i programista musi sie dostosowac. mie ma bata, nie wolno kombinowac bo z programu wyjdzie smiec.
Jak wtedy zrobić "własną konsolę".
A pod x nie ma przypadkiem odpowiednika ScrollConsoleScreenBuffer()? Oj wydaje mi sie ze jest cos takiego. Nie pisalem sporo pod linuxa jesli chodzi o gui wiec nie podam rozwiazania.
Ale mysle ze java ma universalna klase do obslugi konsoli. Jesli nie ma, to sie nie da tego zrobic.
No ale tak czy inaczej, nie wolno zakladac ze stdout to konkretny typ pliku. mozna to sprawdzic jakas funkcja typ handla stdout, ale nawet jak bedzie to konsola, to bedziesz musial poznac jej rozmiary, monitorowac kazda zmiane, i dostosowac swoj program do jej rozmiarow. No i jest przeciez mozliwosc (legalna) ze program zmieni stdout, pod linuxem jest to afair realizowane przez dup2(), a pod windows SetStdHandle(). A tego hooknac nie mozna, wiec zostajesz z niewiadoma.
Jak juz wspomnialem, pod windows tego sie nie da zrobic, bo nie ma metody na synchroniczny hook eventow konsoli. Pod linux - nie wiem.
Reasumujac rysowanie po konsoli to prymitywne operacje GUI. Czy warto z tego kozystac? Pod linuxem pewnie tak, pod windowsem - stanowczo nie.
Lepiej operowac albo na czystym stdin/out/err, albo na czystm GUI. Rysowanie po konsoli jak dziala, to tylko pod linuxem.
Czyli program wypluwa tylko informacje, ktore sa pozyteczne dla usera, albo zajmuje sie rysowaniem okien jezeli wazna jest forma.
funkcje konsolowe dzialaja tylko pod linuxem, choc i tak nie jestem tego pewien. wiec odpowiedz na temat watku - [b]nie uzywac konsoli jako CUI w java[/b].