Gucio

4 lipca - ostatie wypociny przed dziekanam, a potem przyjezdza brat qumpeli i bedzie jazda, poza tym szukam pracy. Bedzie ciezko, ale dam z siebie wszystko.

W message loop: case WM_SHOWWINDOW: CenterDialog(hDlg,GetParent(hDlg)); break; no i implementacja: void CenterDialog(HWND hDlg, HWND Parent) { RECT ParentRect,DlgRect; GetWindowRect(Parent,&ParentRect); GetWindowRect(hDlg,&DlgRect); SetWindowPos(hDlg,HWND_TOP, ParentRect.left+(ParentRect.right-ParentRect.left-(DlgRect.right-DlgRect.left))/2, ParentRect.top+(ParentRect.bottom-ParentRect.top-(DlgRect.bottom-DlgRect.top))/2, 0,0,SWP_NOZORDER | SWP_NOSIZE ); }; Jak chcesz na srodku ekranu to daj jako parent desktop. I wsjo .

Welcome back! Telekomunikacja mnie odciela, a pierwsze co zrobilem po podlaczeniu (nie przez tele komune) to ten post. A teraz biore sie za czytanie tego co przegapilem!

Hmm.... Sluszna uwaga, tyle, ze gdzies to juz chyba czytalem. A juz pamietam. Patrz wyzej! Nie, jeszcze wyzej! - Sorry, za ironie, ale to bylo przegiecie - tyczy sie mutex'ow. P.S. Witamy nowego czlonka na forum.

Sprawdzilem i przyznaje sie do bledu (ale dlaczego w Q2 to dziala jak ta lala? - tego nie kumam, bo innego mechanizmu sprawdzajacego nie ma) Coz, z ta porazka na plecach musze isc dalej :) Mutex'y rzadza.

W prawdzie nie mialem czasu tego sprawdzic, ale ten piekny zapis znalazlem w zrodlach avp oraz q2. W tym drobim byl pieknie opisany (/* Just in case someone a*** launch me again */). Coz, jezeli nie dziala przyznaje sie do bledu - nie sprawdzilem we wlasnym programie. Jednak przekompilowany Q2 dziala dobrze czyli hPrevInstance nie moze byc rowne 0, poza tym gdy odpalam droga kopie - kicha nic sie nie dzieje.

Po wnikliwej analizie problemu dotarlem do takiego oto rozwiazania int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { if (hPrevInstance) return 0; Mysle, ze to dosc proste i rozsadne rozwiazanie.

Help me with buggy GetPixelColor. Nie mam pojecia dlaczego sie sypie i jak to naprawic. Mam nadzieje, ze ktos to juz przetrawil. Dla tych co nie widzieli to code jest na ftp.

W pewnym momencie przesiadka z jednego jezyka programowania na inny jest mechaniczna. Jest to kwestia doswiadczenia i z pewnoscia nie dalbym rady przesiasc sie z C na ASM, ale C, C++, Delphi, WinAPI, i inne twory tej masci - wszystkie sa podobne, maja podobna skladnie i z regoly jakas dokumentacje. Co do baz danych to mam mieszane uczucia. Znaczy sie wole napisac wyspecjalizowany program przeznaczony do konkretnego celu, tak aby faktycznie moznabylo go sprzedac, ale z drogiej strony nie lubie pozbawiac sie elastycznosci i wolalbym cos bardziej uniwersalnego, cos co moge latwo przerobic i dostosowac do innych potrzeb. Swoja droga uzywal ktos Micro-C? Kros tam zamieszal z wskaznikami i nie moge dojsc z tym do ladu?

I'm back! Sprawdzal ktos moje smieci? Jest blad w funkcji GetPixelColor, a wlasciwie to nie wiem co to jest. Wywolywana pojedynczo nie sprawia problemow, ale seriami? To co innego, ponad to Nie jest ona zbyt szybka. Probowalem ja zastapic funkcjami z DibHelp.c, ale efekt ten sam, ba nawet MSDN nie ma na to lekarstwa. Problem jest w switch(nBpp) { /* TUTAJ */ };. Odzyskiwanie koloru z Dib'a o palecie 8 lub mniej bitow itak odbywa sie przez DC. (2 bity jeszcze mozna przyspieszyc, ale na razie trzeba sie tego pozbyc). Moze ktos napisal sprawniejszy odpowiednik GetPixelColor i podzielilby sie nim?

Juz wpozadku, ba nawet zayebiscie i prawie jak trzeba. Niewazne na ftp bedzie wkrodce :) - Brzmi jak reklama. Wpadlem na pomysl u Wojka Czeska. Jak skoncze to dam na ftp.

Mam problem. Caly dzien probuje napisac funkcje pobierajaca pojedynczy pixel z bitmapy. Niestety bezskutecznie, udalo mi sie za to sprawdzic gdzie wskazuje BITMAP.bmBits, i wiecie co - gdzies, ale gdzie to nie wiem. char *bits; $bits = BITMAP.bmBits; Powyzsze raczej nie przejdzie, pzatym nie moge poprawnie obliczyc pozycji pixela. A teraz najciekawsze. Jedziemy na DIB'ach, prawda? A mieszal ktos w kodzie tego kolesia? Bo ja tak i mam zle przeczucia co do tego - na DIB'ach zajmie to nam o wiele wiecej czasu. Wiem pesymista, wybaczcie, dam z siebie wszystko. Wracajac do bitow bitmapy. Powyzsze dziala, ale zapisane tak: char *bits, byte; bits = (BITMAP.bmBits); byte = bits[0]; /* UWAGA */ Z tym, ze to ostatnie robi zwis applikacji - quzwa. P.S Napisze ktos program testowy, ladujacy DIB'a - cos takiego jak zrobilem dla DDB? Bez tego programiku chwilowo ugrzezlem. P.S. Nie moge skompilowac tego programiku od Nicon'a :) Kiedy nastepne spodkanie? Narka.

Konwersja do skali szarosci przydsala by sie do mojego modulu (przy okazji juz oblicza rozmiar bufora). Albo przyjmijmy, ze jest juz szary, wtedy wystarczy przemielic tylko jeden kanal i wyjdzie to samo. Z tego co pamietam spodkanie mialo byc w niedziele, dzis o tej godzinie co niektorzy moga byc zbyt zajeci.

Ja jestem za uchwytami - najwygodniej. Mam tez juz koncepcje co do ciagu znakow, a wlasciwie ustalania rozmiaru bufora na texy, Mianowicie: int GetBufferSize(HBITMAP hbmpBitmap, int nCharWidth, int nCharHeight); A funkcja zajmujaca sie konwersja: int ConvertToAscii(char *cBbuffer, int nBuflen, HBITMAP hbmpBitmap, DWORD flags); Teraz tylko realizacja. Ma ktos sposob na konwersje obrazka do skali szarosci? Chyba tylko tego mi brakuje.

Na ftp zamiescilem programik testowy (NO_NAME_TEST.zip) do jescze nie napisanego modulu, dlatego moze sie jeszcze komus przydac. Zwlaszcza bialemu. Mam tez jeszcze jeden pomysl - konwersja na podstawie jasnosci jednego kanalu. Pytanie propos ftp. Dlaczego TotCmd widi pustke i nic nie moze wyslac? (Polecam AceFTP na te bolaczki).