Fragment

Piszę program, który dość intensywnie wyświetla wiersze oraz zmiany ich zawartości na kontrolce ListView. Pojawia mi się efekt migania poszczególnych wierszy i całej kontrolki. Wygląda na to, że kontrolka nie daje sobie rady z szybką zmianą swojej zawartości. Jednocześnie wiem, że są programy, które tak samo intensywnie odświetlają wiersze na liście np. e-mule. Nie ma w nich żadnego migania. Czy ktoś wie jak pozbyć się tego migania ? Czy właściwym sposobem jest skorzystanie z tzw. virtual ListView czy może zastosowanie całkiem innej kontrolki ? Jeśli tak to jakiej ? Pozdrawiam

Pytając się o maksymalną ilość wątków w aplikacji miałem na myśli obciążenie systemu. Podczas tworzenia wątku system musi zarezerwować pewne zasoby systemowe (np. stos wątku). Poza tym zbyt duża ilość wątków może spowodować drastyczne skrócenie czasu pracy procesora przydzielanego pojedynczemu wątkowi a także zwiększenie czasu potrzebnego na przełączanie między wątkami. Co do książki to MFC czarna księga to wg mnie słaba pozycja. Bardzo polecam Programming Applications for Windows Jeffrey-a Richter-a. Wielowątkowość i wieloprocesowość jest tam wyjaśniona znakomicie. Podobnie jak zagadnienia synchronizacji wątków i kolejki komunikatów. Nie ma tam jednak nic o kwestii obciążenia systemu. Stąd moje pytanie.

Chciałbym dowiedzieć się ile wątków może maksymalnie liczyć aplikacja oraz ile maksymalnie można w niej użyć socketów, event objectów i inych obiektów jądra jednocześnie tak aby nie przeciążać systemu. Czy ktoś z Was zna jakąś książkę lub stronę www zawierającą jakieś wskazówki na ten temat lub może sam coś poradzić ?

Czy istnieją jakieś funkcje niskopoziomowe, które umożliwiałyby napisanie rozszerzonej wersji funkcji WaitForMultipleObjects() ? Chodzi o to, żeby funkcja obsługiwała bardziej skomplikowane warunki wznowienia wątku. WaitForMultipleObjects() działa tak, że wznawia wątek albo gdy jeden z zadanych obiektów jądra zostanie ustawiony lub gdy wszystkie obiekty jądra zostaną ustawione. Ja chciałbym żeby funkcja wznowiła wątek gdy ustawiony zostanie jeden obiekt lub 2 inne (O1 OR (O2 AND O3)). Istnieje co prawda sposób rozwiązania tego problemu za pomocą 2-óch wątków podrzędnych, z których jeden czekałby aż pierwszy obiekt zostanie ustawiony, a drugi wątek czekałby na jednoczesne ustawienie pozostałych obiektów. Wątek główny czeka natomiast czeka na zakończenie obu wątków podrzędnych. Jednak w tym rozwiązaniu nie można stosować jako obiektu jądra mutexu. Czy ktoś zna jakiś inny sposób ?

Dzięki za odpowiedź. Jest to rozwiązanie podobne do tego z dokumentacji SDK, tylko że tam zamiast zmiennej globalnej zaleca się stosowanie event Obcject. Jednak nie rozwiązuje to mojego problemu. W moim programie zamykany wątek ma wykonywać czytanie i zapis do gniazda blokowanego. Tak więc może zdarzyć się sytuacja gdy wątek będzie czekał na odczyt danych z gniazda po wywołaniu funkcji recv() i w tym czasie nie będzie go można w żaden sposób zamknąć stosując te rozwiązanie. Ostatnio jednak doczytałem się, że do gniazda można przypisać uchwyt obiektu jądra, na którym można za pomocą funkcji WSAwaitForMultipleObjects() oczekiwać na nadejście danych do gniazda. Jednocześnie można zastosować globalny event object, który sygnalizowałby chęć zamknięcia wątku. Gdybyśmy wywołując funkcję wsaWaitForMultipleObjects() czekali albo na jego ustawienie albo na nadejście danych do gniazda, problem byłby rozwiązany. Zaznaczam że nie sprawdziłem działania tego mechanizmu. Wszytko to jednak wydaje mi się strasznie toporne. Pod Unixem do sterowania działaniem innych procesów można używać sygnałów, które docierają do nich natychmiast i proces może także natychmiast na niego zareagować. Myślałem, że pod windowsem będzie coś podobnego.

Czy ktoś wie w jaki sposób wątek może przerwać działanie innego wątku. Z góry wykluczam użycie funkcji TerminateThread(), ze względu na to że pozostawia ona po sobie śmieci (np. stos zamkniętego wątku). Poza tym Microsoft nie zaleca jej używania. Zaleca funkcję ExitThread(), ale ta może być wywołana tylko przez zamykany watek.

Niezupełnie jest tak jak piszesz. Program odpalony z okna konsoli to w rzeczywistości 2 programy: interpreter komend konsoli i sam odpalony program. W systemie są to 2 oddzielne procesy, czyli programy. Poza tym np. konsola cygwina umożliwia odpalenie progamów w tle, czyli na jednej konsoli może pracować jednocześnie kilka procesów, co oznacza że jednemu oknu odpowiada kilka programów. Czyli z całym szacunkiem, Twoją metodę sobie podarować niezależnie od tego czy jest się mocnym czy słabym programistą. Ciekawi mnie natomiast to co napisałeś o funkcji MessageBox()odpalonej z NULL-em. Co zwraca GetParent() dla takiego okna ? Rzeczywiście tego nie sprawdzałem, ale zainteresowało mnie to.

Jest to jakaś metoda. Tylko nie podoba mi się duża ilość pracy jaką miałby wykonać korzystający z niej program no i to, że nie będą wzięte pod uwagę programy konsolowe. Poza tym nie wszystkie okna aplikacji muszą mieć ustanowione okno rodzica. Np. możliwe jest odpalenie funkcji MessageBox() z NULL-em jako uchwyt okna rodzica. W Twoim rozwiązaniu będzie ono traktowane jako oddzielny program, a tak przecież nie jest. Chyba jednak lepsza jest moja propozycja.

Nicon, nie każdy program ma tylko jedno okno. Jeśli wyłuskasz wszystkie okna w systemie, to czy jesteś w stanie sprawdzić, które z nich są oknami głównymi programów. Poza tym, czy w twoim rozwiązaniu będą wzięte pod uwagę okna zminimalizowane ?

Pod Windowsem 95, Windows 98 i Windows 2000 służą do tego funkcje Process32First() i Process32Next(). Pod Windowsem NT nie ma tych funkcji, a za to jest inna EnumProcesses(). Myślę, że pod XP jednak są te pierwsze.

Rzeczywiście masz rację. Trochę przekombinowałem, a że działało poprawnie to nie zauważyłem że max() jest niepotrzebny. Dzięki.

Właśnie czytam sobie książkę Jeffrey-a Richtera Programming Applications for Windows (bardzo polecam) i natrafiłem na mały problem. Chodzi mianowicie o to, że wg. autora jak i także wg. dokumentacji SDK, zapis i odczyt zmiennych 32-bitowych można traktować jako jednorodną operację nieprzerywalną przez inne wątki aplikacji. W SDK dosłownie jest napisane tak: "Simple reads and writes to properly-aligned 32-bit variables are atomic." Jednak jest tam także takie zdanie: "Reads and writes to variables of other sizes are not guaranteed to be atomic(...)". Czy to oznacza, że odczyt i zapis zmiennych typów mniejszych niż 32 bity (char i short) nie są operacjami nieprzerywalnymi (ang. atomic) ? Drugie pytanie to co oznacza określenie w pierwszym z tych zdań "properly-aligned" ? Przetłumaczyłem to sobie na właściwie uszeregowana, ale co to oznacza, że zmienna jest właściwie uszeregowana ? Podejrzewam, że odpowiedzi na te pytanie będzie mógł mi udzielić ktoś znający asemblera.

Już wiem. Po wielu trudach sam doszedłem do tego jak to zrobić.

Wyjaśniło się. Ponieważ RECT zawiera dane w jednostach całego ekranu, nie możemy przypisywać jego składowym wartości minimalnego rozmiaru, ponieważ one nie są współrzędnymi w jednostkach całego ekranu. Tak więc w sytuacji, gdy okna znajduje się blisko lewego górnego rogu, efekt zablokowania zmniejszania rozmiaru okna jest jakoś widoczny, a w przypadku gdy okna znajduje się na środku ekranu efektu nie ma. W Twoim kodzie jest więc błąd. Powinno być tak: if msg=WM_SIZING then begin R:=POINTER(LParam); //zmienna R to PRect, czyli zwykły rect, ale jako wskaźnik If R^.bottom [b]- R^.top[/b] <=MinCY then R^.bottom:= [b]R^.top +[/b] MinCY; If R^.Right [b]- R^.left[/b] <=MinCX then R^.right:=[b]R^.left +[/b] MinCX; Result:=1; //w tym komunikacie należy zawsze zwrócić wartość true dla procedury okna end Oczywiście nadal nierozwiązny pozostaje problem użycia lewej i górnej krawędzi okna. //edit by Piasiu ;) Ludzie korzystajcie z tego ładnego przycisku Code podczas pisania postu ;)

No niezupełnie. Spróbuj zmienić rozmiar okna za pomocą lewej lub górnej krawędzi okna. Okaże się, że możesz to robić bez ograniczeń. W dokumentacji jest napisane, że WM_SIZING pozwala kontrolować rozmiar, ale także i pozycję okna. Musisz więc sprawdzać wartość wParam, aby wiedzieć którą składową RECT-a musisz nadpisać. Poza tym miałem dziwny efekt. W przyapdku gdy zwracałem 1 po przetworzeniu WM_SIZING, przeważnie nie było żadnego efektu. Dopiero gdy zwróciłem TRUE, działa poprawnie.