|
milanche
San Francisco
Član broj: 2447
Poruke: 1200
*.oak.inreach.net
|
Prvo pitanje:
nije nista neobicno da thread-ovi unutar MFC biblioteka kod sasvim prostih aplikacija i prostih akcija izlaze sa non-zero vrednostima.
Najcesce vrednosti: -1, -2.
Prost slucaj: napravi u VisualStudio-u dialog-based aplikaciju. Kompajliraj je bez ikakvih promena, startuj i izadji pritiskom na Esc. Videces da je return value jednog thread-a 27 (0x1B) (a i cele aplikacije). Ako pokusas da izadjes pritiskom na 'X' dugme u gornjem desnom uglu, thread (i cela aplikacija) ce izaci sa kodom 0x2.
Iako te return vrednosti (sudeci po Tools->ErrorLookup) imaju vrlo preteca znacenja
(0x1B = The drive cannot find the sector requested, 0x2 = The system cannot find the file specified), to nije nesto sto treba tebe da sekira. Ako MFC dizajneri mogu da zive sa time, mozes i ti.
Znak mnogo ozbiljnijeg dizajn problema (koji je uglavnom tvoja briga) su exceptions koje sibaju kad zatvoris aplikaciju na nedovoljno dobar nacin - naprimer, izbrises buffer, a jos uvek zivi thread pokusava read/write iz tog istog buffer-a.
Takodje, memory leaks su tvoja briga - u destruktoru ili u WM_DESTROY handler-u moras da dealociras svu memoriju koju si alocirao.
Drugo pitanje:
Ako si stavio kontrolu (dugme, combobox, listbox...) na dijalog, i dodelio promenljivu toj kontroli, onda puko brisanje kontrole u resource editoru nije dovoljno, cak je i vrlo nezgodno ako si ostavio definisane kontrol/value promenljive vezane za tu kontrolu. Ako kompajliras/startujes kod, pocece da iskacu exceptions.
Najbolje je prvo otici u ControlWizzard (Ctrl-W) i obrisati sve promenljive vezane za datu kontrolu, po tek onda je izbrisati sa resource editora. Ako si se prevario pa prvo izbrisao kontrolu u resource editoru, nije strasno - ista stvar moze i rucno - odes u header fajl, pa izbrises promenljivu, probas da kompajliras, pa onda ides na svaku liniju u source fajlu gde je prijavljena greska, pa brises/modifikujes.
|
thread exited with code <>0
Re: thread exited with code <>0