Witam
Niedawno zacząłem programować w c# i mam problem - jestem w trakcie tworzenia prostej aplikacji bazodanowej: 4 tabele + 4 DataGridy. W pewnym momencie zaczeły pojawiac się jakieś niezrozumiałe dla mnie błędy - komunikat że nie można wyświetlić formy z designerze - pojawiały się mimo, że nie robiłem nic co mogłoby spowodować takie problemy. Co dziwniejsze po wyjściu z c# i ponownym wejściu wszystko było ok. Działo się tak kilkanaście razy aż w końcu poznikały mi kolumny z datagridów i nie mogę dodać nowych (w DataBindingSource jest ustawione źródło). Też wydaje mi się że nic nie zrobiłem, co mogłoby spowodować taki błąd. Jedyne wyjście to usunąc datagrid i wrzucic od nowa.
Czy ktoś się spotkał z takim problemem? bo nie wiem czy to moja wina, czy problem lezy w niestabilności visual c#
problem lezy w designerze VisualStudio i w czyms co zrobiles, czego on nie przewidzial.
Designer graficzny .Net w Visualu dziala dosc specyficznie -- nie zapisuje sobie nigdzie informacji co jest gdzie poukladane, tylko na biezaco czyta i analizuje specjalna metode - InitializeComponent - i na jej podstawie stara Ci sie wyswietlic podglad okienka. Dokladniej mowiac, on czyta te metode 'linia po linii' i ja wykonuje, tworzac w pamieci obiekty w niej wymienione na poczatku tej metody, konfigurujac 'linijkami' ze srodka metody itd itd. (A)
potem, wyswieta Ci ow podglad, pozwala sie bawic prezentacja tych obiektow, edytowac ich wlasciwosci, tworzyc nowe obiekty, etc. (B)
potem, jak kazesz zapisac plik formatki - oglada te obiekty i na podstawie trzymanych aktualnie obiektow podgladu i pamietanych ich wlasciwosci ... stara sie wygenerowac InitializeComponent na nowo (C)
i teraz do rzeczy..
najczesciej, zmieniles recznie InitializeComponent. nie wazne jak bardzo, nie wazne co dodales/usunales/zmieniles - zrobiles to tak, ze w momencie (A) Visual juz nie jest w stanie zrozumiec kilku z tych linijek ktore sie zmienily. czasem wyrzuca komunikat ze sie nie udalo przeczytac i dalej nie probuje
czesciej zas, w momencie bledu odczytu InitializeComponent, leci jakis wyjatek i Designer wyrzuca mboxa/komunikat z informacja o bledzie i pozwala Ci nacisnac 'ignore and continue' czyli olewac niezrozumialy fragment i czytac nastepne. jesli tak zrobisz i potem zapiszesz plik (C) -- sam sie prosisz o bęcki. Visual czegos nie zrozumial, wiec nie odczytal, wiec przy zapisie to cos wyparuje z InitializeComponent i zostanie stracone na dobre.
czasem sie nawet zdarza, ze Visual cos przeczyta niepoprawnie, utworzy obiekt, skonfiguruje go niepoprawnie - ale, mimo ze dane konfiguracyjne byly zle, to obiekt taki konfig przyjal bez szemrania, nie poszedl wyjatek/blad/etc ze cos nie wyszlo. Designer jest happy, udalo sie odczytac - ale podglad jest niepoprawny. w takim momencie save (C) to znowu katastrofa, bo nowy InitializeComponent bedzie juz zawieral inna konfiguracje
i teraz, ostatni, rzadki przypadek jaki mi w tej chwili przychodzi do glowy - nie musisz zmieniac InitComp zeby sie cos wypierniczylo. ze sposobu dzialania Designera - tworzenie faktycznych prawdziwych obiektow 'tymczasowych' na potrzeby prezentacji - jest w 100% mozliwe, ze obiekty sie ze soba 'pogryzly' podczas konstruowania albo podczas juz ich wizualnej edycji i w efekcie ... same sie uszkodzily. potem save (C) zapisal je razem z uszkodzona konfiguracja i tyle..
scenariusz przykladowy:
- masz ladna calkiem poprawnie dzialajaca i wygladajaca formatke, wyswietlajaca sie w Designerze
- kladziesz na formatke nowy komponent, np. jakies BindingSource, jakis automatyczny lokalizator, cos z jakiejs dodatkowej biblioteczki, albo cos czego 'microsoft' nie przewidzial ze bedzie lezalo razem z innymi... albo chociazby przesuwasz jakas kontrolke w poblize innej i ta inna nagle uznaje ze np. powinna byc parentem tej ktora przesunales w jej poblize
- odpalaja sie specyficzne metody tych obiektow - onparentchanged, onmoved, cokolwiek. kod w nich zawarty powoduje zmiany w konfiguracji innych kontrolek.. i tak dalej
- kaskada zmian propaguje sie po wielu obiektach, w wiekszosci nic sie nie dzieje, w mniejszosci - cos sie moze uszkodzic, albo jego konfiguracja moze byc poprawna - ale juz nie dajaca sie (!) zapisac z powrotem do InitializeComponent
- a Ty tego nie widzisz lub nie zauwazasz, bo patrzyles na cos innego
- save (C) robi demolke
swietnym przykladem kontrolek ktore wygladaja ladnie, wydaja sie ladnie pracowac ale sieja wielke zniszczenie jesli masz skomplikowana formatke to np. GridLayout'er z pakietu DevExpress..
problemow mozliwych jest wiele - ale sa one w 100% deterministyczne. strac chwile czasu i dojdz metoda prob i bledow, ktory komponent z ktorym sie gryzie. skopiuj przy tym sobie oryginalne prawidlowo dzialajce blah.Designer.cs zawierajace InitializeComponent (masz ten plik prawda? nie masz mam nadzieje InitComp w glownym pliku .cs formy..) gdzies na bok, zeby w przypadku demolki moc go odtworzyc i sprobowac znowu.. jak juz wykryjesz co z czym sie kloci - dopiero wtedy mozna szukac rozwiazania.. czasem wystarczy wrecz jedynie zamienic kolejnosc tworzenia/konfiguracji obiektow
Dzięki za odpowiedź.
Wprowadzałem jakies drobne zmiany do InitializeComponent i pewnie cos zepsułem. Czy gdy cofnę zawartośc IC do poprzedniego stanu, wszystko wróci do normy?
Jeszcze jedno pytanie: Jestem w aplikacji podpięty do bazy danych utworzonej przez kreator visual studio. Gdy wykonuje jakies operacje na bazie (dodaje rekordy), w aplikacji widze tego efekty, także po wyjściu i wejściu do aplikacji, czy restarcie kmputera. Ale gdy tylko chce podejrzeć zawartość tabeli w Database Explorerze, wszystko znika i juz w aplikacji tego nie widze. Nie znika tylko to co dodam recznie do tabeli w Database Explorerze. Czy tak powinno byc?
@initializecomponent - w ogolnosci, tak. podejrzyj inne linie z tej metody - jelsi bedziesz sie trzymal formatu takiego jak vs generuje, powinno przejsc. format sekcji w skrocie mozna opisac:
pierwsza - this.zmienna = new kontrolka
druga - wywolanie BeginInit na kazdej kontrolce ktora to obsluguje
trzecia - dla kazdej kontrolki, poustawiac jej wlasciwosci. format: this.kontorlka.property = wartosc. wartosc musi byc wartoscia stala, inna kontrolka, nawet proste wyrazenia typu 5+6 moga juz nie przejsc. nie wolno wywolywac zadnych metod, no moze poza kontrolka.jakascollection.AddRange(new tablica[]{wartosci..})
czwata - konfiguracja samego okna, dopiero na samym koncu ustawiasz property okna, dodajesz kontrolki do okna itp
piata - na kazdej kontrolce ktorej wczesniej robiles BeginInit, teraz robisz EndInit
kolejnosc init/end'owania kontrolek moze miec znaczenie! szczegolnie przy BindingSource..
drugie pytanie - szczerze, na tyle ile Ciebie zrozumialem, zachowanie jest dziwaczne.. tak jakby DataBase Explorer robil Ci DELETE * na tablicach, co troche jest bezsensem.. moze przypadkiem przy jego pomocy przegenerujesz baze na nowo?
No właśnie jest to bardzo dziwne, bo jak zajrzę do tabeli to skasowane jest wszystko co programowo dodałem w aplikacji, a to co dodałem z poziomu Database Explorera zostaje. Tak jakbywszystko co dodam w aplikacji było nietrwałe. Może DataSet nie zapisuje tego do pliku bazy? Wykonuję metode AcceptChanges(). Z drugiej strony po wyjściu z Visual c# i wejsciu jak też po wyjściu z aplikacji i wejściu dane są widoczne, aż do odpalenia Database Explorera.
Nic nie zmieniałem w konfiguracji DE.
O jakiej bazie mowimy? Moze Database Explorer podmienia kopie bazy? Moj kumpel mial taki efekt, kiedy pisal cos na komorke. Wtedy emulator kopiowal sobie baze stworzona przez kreator do emulatora, w zwiazku z czym aplikacja dzialala na kopii, ktora po zamknieciu emulacji leciala w kosmos.
Baza jest stworzona przez kreatora Vsual Studio, ma rozszerzenie sdf.