🚀 go-pugleaf

Dnia Fri, 12 Mar 2004 10:01:56 +0100, Krzysztof Jarocki 
<tek...@poczta.onet.pl> napisał:

> Czesc.
>
> Mam problem z osadzonymi kontrolkami UserControl.
> Jesli zbuduje zestaw pojedynczych kontrolek (UC)
> i dalej osadzam je w kontrolce zbiorczej (UC) lub na formie
> wszystko jest OK.
> Ale gdy po jakims czasie robie zmiany, osadzone kontroli
> znikaja gdy zrobie cos w kodzie.
> Ich ponowne osadzenie nie jest mozliwe bo kod konstruktora
> zawiera pelne definicje (znikaja tylko wizualnie, kod pozostaje
> i efekt jest taki ze potem brak informacji o nich podczas kompilacji)
> ale gubi referencje.
> Otrzymuje komunikat:
> "String reference not set to an instance of a String".
>
> Czego moge sie tutaj czepic, gdzie szukac rozwiazania ?

Jeszcze mi sie cos takiego nie zdarzylo, ale poniewaz mam na koncie
dopiero jeden wiekszy projekt w C# (VS 2003 .NET), wiec wszystko
przede mna ;). Ale odpowiadajac na Twoje pytanie, aktualnie przychodzi
mi do glowy tylko usuniecie atrybutow reprezentujacych w kodzie klasy
te kontrolki oraz usuniecie z konstruktorow linijek powolujacych nowe
instancje klas tych kontrolek. Po tym zabiegu dodanie nowej kontrolki
o tej samej nazwie nie powinno stwarzac problemow. Jesli jednak zniklo
Ci duzo kontrolek, to bedziesz mial co robic ;) A tak swoja droga, to
polecam robienie czestych kopii zapasowych rozwijanych projektow.

-- 
pozdrawiam,
Marcin Zaleczny

U�ytkownik "Marcin Za��czny" <m_zal...@poczta.onet.pl> napisa� w
wiadomo�ci news:opr42z5nb0sqthqm@news.tpi.pl...
[...]
> Ci duzo kontrolek, to bedziesz mial co robic ;) A tak swoja droga, to
> polecam robienie czestych kopii zapasowych rozwijanych projektow.


Dzieki.

W zasadzie doszedlem do rozwiazania w stylu:
Kopiuje cala sekcje InitializeComponent()
do komentarza /* IC() */
Jesli IC() sie wykrzaczy, czyli kontrolki znikly
to najczesciej w IC() konstruktor cos wycial i teraz
definitywnie tego tam brak.
Wyciagam kopie z komentarza /* IC() */,
wklejam i wszystko jest OK.

Pytanie pozostaje, dlaczego VS po zmianie jakichs
elementow na kontrolce tak radykalnie rozwala projekt
glownej kontrolki ?

I jeszcze.
Mowisz o usunieciu zapisow o zmiennej i o budowaniu
instancji. Ale mam sytuacje w ktorej to nic nie daje.
Zapisy istnieja jeszce gdzies i system uparcie wywala
komentarz o bledzie.

Doszedlem do takiego momentu, ze blad jest umiejscowiony
w UC (skladajacej sie z  innych UC, a te juz z elementarnych
kontrolek Label, TextBox, itp.)
Nawet wywolanie DesignView powoduje ze otrzymuje
komunikat "String reference not set to an instance of string.
(cos tam cos tam) className".

Krzysiek

U�ytkownik "Krzysztof Jarocki" <tek...@poczta.onet.pl> napisa� w wiadomo�ci
news:c2ru9h$pjr$1@news.onet.pl...
> Czesc.
>
> Mam problem z osadzonymi kontrolkami UserControl.
> Jesli zbuduje zestaw pojedynczych kontrolek (UC)
> i dalej osadzam je w kontrolce zbiorczej (UC) lub na formie
> wszystko jest OK.
> Ale gdy po jakims czasie robie zmiany, osadzone kontroli
> znikaja gdy zrobie cos w kodzie.
> Ich ponowne osadzenie nie jest mozliwe bo kod konstruktora
> zawiera pelne definicje (znikaja tylko wizualnie, kod pozostaje
> i efekt jest taki ze potem brak informacji o nich podczas kompilacji)
> ale gubi referencje.
> Otrzymuje komunikat:
> "String reference not set to an instance of a String".
>
> Czego moge sie tutaj czepic, gdzie szukac rozwiazania ?
>
> Krzysiek
>
>


A pod czym tworzysz projekty?
SharpDevelop robi nagminnie takie rzeczy, ale Visual Studio tez potrafi
namieszac,
podstawowa zasada jest nie dotykac kodow wygenerowanych automatycznie (w
zadnym wypadku nie dotykac InitializeComponent), a definicji wlasnych
zmiennych nie umieszczac pod tymi wygenerowanymi automatycznie, tylko gdzies
dalej, najlepiej miedzy definicjami funkcji.
Nie jest to byc moze eleganckie, ale gdy zaczelem tak robic, przestaly mi
znikac kontrolki i handlery do zdarzen.


Mam nadzieje ze to Ci cos pomoze

Tomek

Dnia Fri, 19 Mar 2004 02:02:00 +0100, Krzysztof Jarocki 
<tek...@poczta.onet.pl> napisał:

> U¿ytkownik "Marcin Za³êczny" <m_zal...@poczta.onet.pl> napisa³ w
> wiadomo¶ci news:opr42z5nb0sqthqm@news.tpi.pl...
> [...]
>> Ci duzo kontrolek, to bedziesz mial co robic ;) A tak swoja droga, to
>> polecam robienie czestych kopii zapasowych rozwijanych projektow.
>
>
> Dzieki.
>
> W zasadzie doszedlem do rozwiazania w stylu:
> Kopiuje cala sekcje InitializeComponent()
> do komentarza /* IC() */
> Jesli IC() sie wykrzaczy, czyli kontrolki znikly
> to najczesciej w IC() konstruktor cos wycial i teraz
> definitywnie tego tam brak.
> Wyciagam kopie z komentarza /* IC() */,
> wklejam i wszystko jest OK.

Przyznam, ze to niezly pomysl. A niezle pomysly pozwalaja
zaoszczedzic sporo czasu :).


> Doszedlem do takiego momentu, ze blad jest umiejscowiony
> w UC (skladajacej sie z  innych UC, a te juz z elementarnych
> kontrolek Label, TextBox, itp.)
> Nawet wywolanie DesignView powoduje ze otrzymuje
> komunikat "String reference not set to an instance of string.
> (cos tam cos tam) className".

Widze, ze rozbudowane kontrolki stworzyles. Aktualnie jednak ciezko
mi wskazac przyczyne problemow. Przypuszczam, jednak ze to gdzies
w konstruktorze a scislej w IC() lub w metodzie podpietej do zdarzenia
odrysowania kontrolki (o ile taka posiadasz). Nie wiem jak to jest
z bledami zglaszanymi w czasie przejscia do DesignView kontrolki, ale
nie wyswietla Ci numeru linii kodu wystapienia bledu?

Tak swoja droga zastanawiam sie dlaczego w DesignView kontrolki nie
widze efektow dzialania funkcji obslugujacej odmalowanie jej na ekranie,
natomiast w formularzu, do ktorego ja dodalem wszystko jest OK.

-- 
pozdrawiam,
Marcin Zaleczny

U�ytkownik "Tool" <sorry@no.spam> napisa� w wiadomo�ci
news:c3e782$iu0$1@nemesis.news.tpi.pl...

> A pod czym tworzysz projekty?
> SharpDevelop robi nagminnie takie rzeczy, ale Visual Studio tez potrafi
> namieszac,

Visual Studio 2003


> podstawowa zasada jest nie dotykac kodow wygenerowanych automatycznie (w
> zadnym wypadku nie dotykac InitializeComponent),

Niby tak, zgadzam sie.
Jednak przez ten problem musialem szukac roznych rozwiazan.
I jak na moj "psi swed" dochodze do wniosku, ze logika konstruowania
kontrolek
User Controls i Windows Form ma pewien model.
Trzymajac sie scisle tego modelu udaje mi sie generowac zmiany w kontrolkach
z ingerencja w kod i w zasadzie wszystko jest OK.

Moj problem jest inny.
Kontrolka jest juz z jakims bledem, ktory powstal i przyczyna a takze miejce
poprawki
sa nieznane.
Nie moge dojsc gdzie podlubac aby sie zamknal.

Przy probie przejscia do miejsca bledu, Visual przenosi mnie do sekcji
deklaracji
przestrzeni nazw (using).

> a definicji wlasnych
> zmiennych nie umieszczac pod tymi wygenerowanymi automatycznie, tylko
gdzies
> dalej, najlepiej miedzy definicjami funkcji.

To tez zauwazylem.
On sobie ladnie oznacza miejsce wlasnego kodu i byc moze jest za glupi aby
sprawdzic czy jest tam tylko jego kod, czy tez moj.
Celna uwaga w sumie.

Pozdrawiam,
Krzysiek