Trace

Swego czasu miałem podobny problem, rozwiązałem go jednak w inny sposób. Stworzyłem sobie nową klasę okna i na tabie umieszczałem jedynie okno tej klasy. Dopiero na nim znajdowały się poszczególne kontrolki. Kiedy użytkownik zmieniał zakładkę, przy pomocy funkcji ShowWindow ukrywałem stare okno bazowe (SW_HIDE), a nowe pokazywałem (SW_SHOW). Z tego co mi wiadomo podobnie działają równierz taby w property sheetach więc metoda ta nie była zła. Pozdrawiam :)

Może spróbuj pogrzebać trochę w tym pliku mysql_com.h i zobaczyć co jest przyczyną błędu? Ja w ten sposób odkryłem, że wypada definiować wersję internet explorera w programach pod windowsa :P

Wrzucić to do WM_PAINT? Tylko wtedy zamiast GetDC używaj BeginPaint, inaczej tekt będzie ci cały mrugał.

A tak wogóle to do wyświetlania tekstu znakomicie nadają się kontrolki static, wtedy nie trzeba sobie zaprzątać głowy czcionkami, kolorami, tłem i innymi pierdołami. Pozdrawiam.

Błąd popełniasz przy tworzeniu statica. Na HMENU rzutujesz jedynie wartość 250, a dopiero potem dodajesz do tego i. To powoduje, że id kontrolki jest inny, niż zamierzony. Aby to naprawić, wystarczy wstawić (250+i) w nawiasy :). Wtedy wartość całego wyrażenia będzie rzutowana na HMENU i w konsekwencji id kontrolki będzie miał właściwą wartość.

hPoletxt[i] = CreateWindow("static", "tekst", WS_CHILD | 
WS_VISIBLE, 11, 136+(i*18), 388, 18, hwnd, 
(HMENU)(250+i), hInst, NULL); 

Po tej zmianie SetDlgItemText będzie działał jak należy.

WM_SETTEXT nie działał ci, ponieważ zapomniałeś tablicę hPoletxt zadeklarować jako static (była usuwana zaraz po zakończeniu WM_CREATE), więc komunikat wysyłałeś do jakiegoś całkowicie dowolnego obszaru pamięci :P To by było na tyle. Pozdrawiam.

Do ustawiania tekstu w staticu i edicie używasz funkcji SetWindowText. I to tutaj tkwi problem, gdyż funkcja ta służy do innych celów. Zamiast tego skorzystaj z SetDlgItemText(podając uchwyt okna-rodzica oraz id kontrolki), bądź wyślij bezpośrednio do kontrolki komunikat WM_SETTEXT.

 case 201:
{
/*
Tu pojawia się mój pierwszy problem.
Chcę, aby po kliknięciu w button Szukaj, w staticu hPoletxt[1]
pojawił się tekst "!!!", jednak się nie pojawia :(
*/
// id hPoletext[1] to 251
SetDlgItemText(hwnd, 250 + 1, "!!!");
break;
} 

Teraz listbox. Z tego co pomiętam, rodzic jest zawiadamiany o podwójnym kliknięciu w listboxie poprzez komunikat LBN_DBLCLK. Musisz więc zmienić:

 case 209: // ListBox

/*
Tu pojawia się mój drugi problem
Chcę, aby po podwójnym kliknięciu na element z listboxa
zawartosc pola została skopiowana do pola hEdit1
*/
{
// intrukcja switch, która tu się znajdowała, jest zbędna :P
if (HIWORD(wParam)==LBN_DBLCLK)
{
index = SendMessage (hList, LB_GETCURSEL, 0, 0 ) ;

// to LB_GETTEXT było wysyłane do hwnd... Rozumiem, że to tylko niedopatrzenie :P
SendMessage (hList, LB_GETTEXT, index, (LPARAM) wyraz ) ;
SetDlgItemText(hwnd, 207, wyraz);
return 0;
}
break;
}

A tak na marginesie, to nie rozumiem, dlaczego wszystkie zmienne są globalne i zadeklarowane na początku programu... Nawyki z Pascala(Delphi)? Niewiem jak sądzą inni, ale dla mnie kod staje się przez to mniej czytelny. Pozdrawiam.

Spróbój też pokombinować z ListView_Update, np. wysyłając LVM_UPDATE do wszystkich itemów lub tylko do większych niż dodany. Może pomoże.

Bład tkwi w tym, że zwracasz referencję do obiektu tworzonego lokalnie. W chwili, gdy zakończy się działanie wewnątrz przeciążonego operatora, wszystkie obiekty w nim stworzone są usuwane z pamięci i zwrócona referencja wskazuje na nic.

Rozwiązaniem tego problemu jest zwrócenie obiektu przez wartość. Twój przeciążony operator powinien wyglądać więc tak:

X operator+(const X& x2)
{
    X kopia_wyjsciowa;

    // operacje sumujące tabilce z this i x2

    return kopia_wyjsciowa;
}

Tylko pamiętaj o prawidłowym skonstruowaniu konstruktora kopijącego, gdyż odgrywa on w procesie przypisania kluczową rolę.

Hehe... Poszukaj w C:\Windows\System, albo C:\Windows\System32 ;) Jest to biblioteka dostarczana razem z systemem windows, więc nie musisz martwić sięo rozpowszechnianie jej razem z kopią swojego programu. Aby korzystać z jej dobrodziejstw w Devie (5.0 Beta) wystarczy dodać:

#include <shlwapi.h>

I zlinkować program z biblioteką libshlwapi.a (w katalogu Dec\lib). I będzie działać (myślę, że w Dev4 i każdym innym kompilatorze robi sie to tak samo).

one_eddie napisał:

sedef ma racje podany przyklad jest bledny powinno byc:

int** mxData = new int[a];
for (int i = 0; i < a; ++i)
   mxData[i] = new int[b];

Dostajesz macierz o rozmiarze axb
Ze zwalnianiem podobnie

A nie powinno być

int** mxData = new (int *)[a];
for(int i = 0; i < a; i++)
    mxData[i] = new int[b];

for(int i = 0; i < a; i++)
    delete [] mxData[i];
delete [] mxData;

bądź

int * mxData = new int[a];
for(int i = 0; i < a; i++)
    mxData[i] = (int)(new int[b]);

for(int i = 0; i < a; i++)
    delete [] (int *)mxData[i];
delete [] mxData;

Obie metody są jednakowo dobre, gdyż każdy wskaźnik można przedstawić za pomocą liczby :) Sprawdzałem i w obu przypadkach mój gcc-3.3.4 nie zgłaszał błędów :)

kAzek ma rację... Sprawdziłem i po wysłaniu BM_SETCHECK nie dostaję komunikatu WM_COMMAND. Wydawało mi się, że kiedyś takie rowziązanie wykorzystałem w jednym z moich programów, ale tam wysyłałem do checkbox BM_CLICK i wtedy w WM_COMMAND dopiero WM_SETCHECK i inne akcje... Sorx za wprowadzenie błąd
Errare humanum est :)

Nie wiem, czy ma to jakiekolwiek znaczenie i czy w jakiś sposób mój post ci pomoże... Mam nieco odmienną składnię w pliku "H" i mi Dev wszystko ladnie kompiluje. Zamiast jednego podkreślnika przed declspec mam dwa, a w deklaracji funkcji słówko EXPORT wstawiam dopiero po definicji typu zwracanej wartości. Tak więc twój plik u mnie wyglądałby tak:

#ifdef __cplusplus
#define EXPORT extern "C" __declspec(dllexport)
#else
#define EXPORT __declspec(dllexport)
#endif
BOOL CALLBACK EXPORT EdrCenterTextA (HDC,PRECT,PCSTR);

A gdyby to nie pomogło:

extern "C"
{
    BOOL CALLBACK __declspec(dllexport)EdrCenterTextA (HDC,PRECT,PCSTR);
}

Aha, jeszcze jedno. W pliku "C" windows.h dołączam przed plikiem "H" od dlla. Jeszcze raz powtarzam, ze nie mam zielonego pojęcia, czy ma to jakieś znaczenie. Spróbować jednak nie zaszkodzi, bo kto szuka, nie błądzi :P

Czy na pewno trzeba posuwać się aż do subclassingu? Zawsze myślałem, że checkbox wysyła po kliknięciu (bądź wysłaniu BM_SETCHECK) komunikat WM_COMMAND tak, jak zwykly button...

Przerabiając trochę twój kod to będzie coś w tym stylu:

LPSTR Bufor;
Rozmiar = GetWindowTextLenght(Adres);
Bufor = (LPSTR)GlobalAlloc(GPTR, Rozmiar+4);
GetWindowText(Adres, Bufor, Rozmiar+1);

lstrcat(Bufor, "web"); // sklej napisy

Cały myk sprowadza się do tego, żeby zarezerować w buforze miejsce na dwa stringi: ten z okna i ten który chcesz dąłączyć. Funkcja lstrcat dokleja string podany jako drugi argument, do stringa będącego argumentem pierwszym :]

Nie bardzo rozumiem o co ci chodzi... Aplikacja nie będzie widoczna w trayu, jeżeli jej sam tam nie dodasz. Jeślii chcesz stworzyć program, który nigdzie nie będzie widoczny podczas pracy (ani w trayu, ani na pasku zadań), to po prostu nie twórz mu okna (ew. ukryj je funkcją ShowWindow(hwnd, SW_HIDE).

Teoretycznie można by też przy pomocy SetWindowLong ustawiać i usuwać styl odpowiedzialny za wyświetlanie bitmapy na przyciku (bodajże BS_BITMAP, albo coś w tym stylu :P)... Ale podobnie jak codeguy nie testowłem tego sposobu - tak mi spontanicznie do glowy przyszlo, jako alternatywa...

Bloodshed udostępnia bibliotękę do pracy z MySQL. Nie jest ona standardowo dołączana do programu, ale możesz ją sciągnąć przy pomocy narzędzia uaktualniającego zawartego w Devie. Jest w niej bodajże jeden plik nagłówkowy, po lekturze którego będziesz już mniej więcej wiedział co i jak :D

Możesz też to zrobić tak:

char pszBuffer[] = "C:\Cos tam\Cos tam2\Cos tam3\pliczek.cpp";
char * pName = PathFindFileName(pszBuffer);

lub aby mieć nazwę w osobnym buforze:

char pszBuffer[] = "C:\Cos tam\Cos tam2\Cos tam3\pliczek.cpp";
char pszName[256];
lstrcpy(pszName, PathFindFileName(pszBuffer));

Deklaracja funkcji PathFindFileName znajduje się w pliku Shlwapi.h. Można tam też znaleźć dużo więcej ciekawych funkcji do operacji na sieżkach. Po więcej odsyłam do MSDN :)

DevC++ nie zawiera żadnej z tych bibliotek dll. Są one częścią systemu Windows i są współdzielone przez wszystkie aplikacje korzystąjące z danej wersji kontrolki RichEdit. Nie musisz się martwić brakiem tych plików w kataloga Dev'a.

Co do drugiego pytania nie mam pewności i polecam Ci przeszukanie stron Microsoftu. Wydaje mi się, że nowsze systemy są zgodne "w dół" i zawierają starsze wersje tych bibliotek. Natomiast trudno mi sobie wyobrazić sytuację, w której MS byłby tak dalekowzroczny i do starszych wersji systemu dałączał jakieś biblioteki mające zapewnić zgodność z technologiami rozwijanymi w nowych oknach :) Bill Gates nie ma przecież wehikułu czasu

Tym pokrętnym sposobem próbuję powiedzieć, że kodowanie RichEdita w oparciu o bibliotekę przeznaczoną dla win98 zapewni zgodność ze wszystkimi nowszymi wersjami okien. Jeżeli natomiast będziesz używał tej do XP, to trudo oczekiwać poprawnego jej działania w np. WinME. Moim zdaniem program po prostu wyrzuci, że nie może znaleźć dll. Powtarzam jednak, że nie jestem tego pewien i najlepiej byłoby, gdybyś sam poszukał informacji na ten temat

Co więcej - biblioteka ta znajduje się prawdopodobnie tylko w WindowsXP i programy które napiszesz w oparciu o nią bedą działały wyłącznie na tej wersji okienek! No chyba, że MS wypuści jakiś patche uaktualniające poprzednie wersje Windowsa Tak więc - jeżeli masz WinXP wystarczy, że na początku programu (przed utworzeniem RichEdita) dasz LoadLibrary("Msftedit.dll"); i powinno działać :D

Nie wiem czy to nadal aktualne, ale w którym dokładnie miejscu Ci to nie działa? Czy program "wchodzi" w pierwszą instrukcję warunkową? Daj jakies MessageBoxy albo asserty i zobacz co konkretnie szwankuje...

Hmm, chyba najlepszym rozwiązaniem byłoby stworzenie czegoś na wzór aplikacji klient - serwer, tzn. jeden program tworzy okno i normalnie z nim pracuje, natomiast drugi pobiera uchwyt do okna utworzonego przez program pierwszy (FindWindow) i komunikuje się z nim przy pomocy komunikatów... Możesz też pokombinować z procesami i semaforami... Dużo ciekawych rzeczy na ten temat można znaleźć na https://www.extremeprog.host.sk/listing.php?category=5. Wybacz ciekawość, ale nie mogę się domyśleć, do czego mogłoby Ci to być potrzebne :)

Twoja kontrolka obsługując komunikat WM_PAINT wywołuje funckję DrawRectangle, w której do pobrania kontekstu używasz funkcji GetDC. Wydaje mi się, że to jest przyczyna twoich problemów z miganiem. Zasadniczo w obrębie WM_PAINT nalezy pobierać kontekst funkcją BeginPaint i zwalniać go przy pomocy EndPaint. Tak więc kod twojej funkcji powinien wyglądać tak:

//X i Y to miejsce gdzie maja byc narysowane kwadraty
inline void DrawRectangle( HWND hwnd, int X, int Y, HBRUSH hBrush)
{
RECT rect;
SetRect( &rect, X + 1, Y + 1, X + CellSize.x - 1, Y + CellSize.y - 1 );
PAINTSTRUCT ps;
HDC hDc = BeginPaint(hwnd, &ps)
X += CellSize.x -15;
Y += CellSize.y -15;
Rectangle(hDc,X,Y,X+CellSize.x,Y+CellSize.y);
FillRect( hDc, &rect, hBrush );
EndPaint(hwnd, &ps);
}; 

Jeżeli w obsłudze WM_PAINT gdzies jeszcze wywołujesz GetDC, to zmien to analogicznie jak powyżej. To powinno załatwić sprawę :)

Co do nie działających DialogBoxów - nie mogłem dopatrzyć jakiegoś racjonalnego wyjaśnienia takiego stanu rzecz (no może poza brakiem return FALSE w funkcji obsługującej DIaloga - domyślam się, ze po prostu nie wklejałeś kodu tej funckji). Może pokaż jeszcze jak deklarujesz tego dialoga? I nie wiem jak jest w Dev4, ale w 5 plik zasobów trzeba dołączyć do kompilacji w opcjach projektu...

Aha, jeszcze rada na przyszłość - źródła naprawdę lepiej się czyta, gdy są sformatowane jak źródła :)

DOPISEK:
Przeanalizowałem jeszcze raz ten kod i zaintrygowała mnie jedna rzecz: czy mówiąc o nie działających MessageBoxach masz na myśli te, które wyświetlasz po próbie utworzenia DialogBoxa? Jeżeli tak to najprawdopodobniej tworzysz niewidzialne okienko, które zatrzymuje ci program. Tu pojawiają się dalsze pytania... Czy po próbie wyświetlenia DIalogBoxa program ci "zwisa"? Jeżeli tak, to jest to prawie na pewno błąd w zasobach - przez to nie działają i MessageBoxy i Dialog.

Jeżeli to DialogBox, to obsłuż komunikat WM_INITDIALOG zamiast WM_CREATE i tam wczytaj bitmape. Nie jestem pewien, ale wydaje mi się, że DialogBoxy nie otrzymują komunikatu WM_CREATE...

Można też utworzyć nowy wątek odpowiedzialny za ruch zwierząt, chociaż w tym przypadku rzezczywiście lepiej obsłużyc WM_TIMER :)

Prawdopodobnie masz rację. Sam sciągnąłem informator maturalny z infy i nie było tam nic o programowaniu grafiki. Ale w takim razie dlaczego standardowo w programie liceum jest moduł graph do Pascala? Ja tam wolę się zabezpieczyć. A przecież nawet jeżeli na maturze tego nie będzie, to zdobyte doświadczenie na pewno kiedyś zaprocentuje. Tego jestem pewien :)