Integracja Resgen.exe z VStudio 2008 i ściąganie stringów

Mam taki problem. Mam gołe i wesołe Visual Studio 2008. Na stronie Microsoft
(http://msdn.microsoft.com/en-us/library/7k989cfy(VS.80).aspx)
jest napisane, że kiedy buduję aplikację, Visual Studio wywołuje program resgen.exe by skonwertować moje zasoby *.resx do klasy nazywanej Resources.

Jest mi to potrzebne do stworzenia różnych wersji językowych mojego programu (stringi pobierane z resourców), gdyż na stronie:
http://www.mysuperiorgames.com/resources.html
opisano ściąganie tych stringów z pliku *.resource za pomocą właśnie klasy Resources:

Resources.GetString("goodDay");

Ściągnąłem SDK ze strony MS, w którym już jest Resgen.exe. Co mam jednak zrobić, by po dodaniu dowolnego pliku resource.resx do programu mógłbym otrzymać automatycznie statyczną klasę Resources żeby za jej pomocą pobierać stringi z plików *.resource? Czyli jak mam zintegrować Visual Studio z Resgen.exe i zmusić VS do używania Resgena?

Kompilowanie zasobow powinno dzialac z autoamtu. Poczytaj o satellite assembly

Kompilowanie zasobów działa, tworzenie klasy Resources nie działa. Kolega ma Resharpera i mówił, że może dlatego u niego nie ma z tym problemów a u mnie są.

raczej nie na czystym expresie dziala bez problemow.

Swoja draga sa narzedzia do multilang - lub mozna pisac swoje (bardziej cool dla tlumaczy co nie chca dotykac informatyki)

Zrobiłem tak jak mówisz i nauczyłem się pisać Satellite Assembly. Bardzo mi się to podoba. Działa super. Dzięki za radę.

Nadal jednak nie wiem dlaczego nie mam z poziomu Visual Studio dostępu do tej klasy Resources :/

Które narzędzie do Multilang polecasz?

0. satellite? mam nadzieje ze robisz to standarodow przez designera i localizable/language na Form/UserControl :) pytam, bo widzialem juz wiele karkolomnych recznych metod..

1. masz w projekcie plik Properties/Resources.resx ?

2. jest on "rozwijalny"?

3. jest pod nim niewyszarzony plik "Resources.Designer.cs" ?

4. tenże plik nie jest pusty i zawiera klase Resources we właściwym namespace?

5. czy we właściwościach pliku Resources.cs opcja CustomTool brzmi:ResXFileCodeGenerator ?

6. jesli ta opcja jest pusta, wpisz to. jesli nie jest pusta - podaj nam co tam jest napisane

7. jezeli namespace jest bledny, sprawdz opcje budowania projektu i 'default namespace' - i popraw na wlasciwa, albo dorzuc sobie usinga wlasciwego, jezeli jest pusty - sprawdz czy w ogole masz w Resources.resx jakies zasoby i czy punkt 5 na pewno jest poprawny

8. jest wyszarzony? prawoklik na nim i "include"

9. dziwne. visual zawsze go odtwarza nawet jak sie go wywali. podaj nam wszystkie wlasciwosci pliku Resources.resx jakie Visual Ci pokazuje

10. prawoklik na projekcie, wlasciwosci, otworzy sie wiadomy panel konfiguracyjny, zakladka 'resources' i klik na link po srodku

Oj:) chyba robię to karkołomnie:)

Jakie localizable/language na Form/UserControl? Nie rozumiem. Nie mam takiej opcji w menu kontekstowym dla formy. Zresztą potrzebuję mieć dostęp do języka wyżej, poza formą. Po prostu dodałem plik *.resx do projektu i nazwałem go:
NazwaProjektu.pl-PL.resx

dla innej wersji językowej dodam na przykład:
NazwaProjektu.en-UK.resx

1.tak
2.tak
3.tak
4.nie do końca, jest namespace projektu + ".Properties", w środku jest internal class Resources

5.nie było tej opcji, dodałem i...
"The custom tool 'ResXFileCodeGenerator' failed. ResX file Data at the root level is invalid. Line 1, position 1. cannot be parsed."

Zmieniłem namespace usuwając ".Properties". Jest dostępne Resources z poziomu MainForm-a :) Super:D Dzięki:D

@quetzalcoatl

ad 0) jakich bo jestem zainteresowany. Oglądałem też różnorakiego rodzaju narzędzia (tak aby właśnie programista nie dotykał języka a tłumacz programowania czy innych skomplikowanych rzeczy).

Na pewno obaj zauwazyliscie, ze jak edytujecie formatke/kontrolke, to czasem/czesto tworzy sie "pod nia" abcde.resx ktory trzyma jakies-tam zasoby dla niej, a w pliku .designer.cs w initializecomponent designer umieszcza linie wyciagajace te zasoby zamiast hardcodowanych wartosci.

Wszysktie resourcemanagery sa przeystosowane do pracy wielo-jezycznej/narodowosciowej. W zaleznosci od S.Threading.Thread.Current.CurrentUICulture, resourcemanager bedzie wybieral albo z domyslnego resx'a, albo z resx.a odpowiadajacego jezykowi watku gui:

• blahblah.resx ----default master fallback
• blahblah.en.resx -- fallback dla jezyka EN
• blahblah.en-US.resx -- zasoby dla jezyka EN kultura US
• blahblah.en-GB.resx -- zasoby dla jezyka EN kultura GB
• blahblah.pl-PL.resx
  ...itd

tak wiec jesli sobie takie pliki dodacie, natychmiast wepna sie one 'pod' formatke a'la' glowny resx i ich zawartosc podczas kompilacji poleci jako satellite w katalogach /en i /pl. niestety te pliki resx NIE beda nigdy mialy swoich .designer.cs na wzor /properties/resources.resx. visuale do 2008 tego nie potrafily, nawet jesli sie postarac o reczna edycje pliku projektu :|

Jak operujecie na designerze formatek/kontrolek, operujecie na kodzie .designer.cs/initializecomponent oraz na pliku master-fallback formatki, czyli blah.resx. To wie prawie kazdy kto choc raz wlaczyl designera. Malo kto stosunkowo jednak wie, ze designer potrafi takze edytowac pliki formatka.en-us.resx i jemu podobne.

Każda pochodna SWF.Form i SWF.UserControl ktorą mozesz obrabiac click&play w designerze dostarcza 2 PROPERTIES nazywajacych sie: Localizable typu bool oraz Language typu CultureInfo. Wykapitalikowalem slowo dla BorysBe: właściwosci szukaj w "Properties" komponentu ktory edytujesz, taki panel rozwijany z lewej/prawej strony desktopu visuala, z lista roznych Text,BackgroundColor itp... Jak wyswietlisz to dla Form albo UserControl (musisz miec ZAZNACZONA 'pusta przestrzen' edytowanej rzeczy. nie panel, nie button, tylko pusta szarawą przestrzen 'ciała' formy/kontrolki). Tylko one to maja, jako ze sa one sa top-level, rootami w drzewie kontrorek edytora. Zeby dobrac sie do tych properties.

Po ustawieniu Localizable na 'true' nagle aktywuej sie Language i mozna sobie sybrac jezyk aktualnie edytowany. Uwaga: to oznacza, ze jedna formatka bedzie miala jeden glowny, domyslny wyglad, i N innych, zapisanych w .blah.xx-yy.resx. Jezeli wybierzecie jezyk Polski(PL), designer stworzy .pl-PLresx i bedziecie od tej pory poprzez designera edytowac tenze plik, a pozostale zostana bez zmian. Aby powrocic do edycji glownego wygladu, nalezy wybrac Language "puste", to z czubka listy.

Specjalnie napisalem domyslny wygląd a nie 'teksty'. Designerowa lokalizacja formatek pozwala nie tylko na podmiane tekstow. Jezeli przelaczyce sie na .de i przesuniecie button, przelaczycie sie na .pl -- button bedize w starej pozycji. Żadnego szlifowania rozmiaru/pozycji per-pixel w .pl-pl.resx! po porstu przelaczasz jezyk designera, przesuwasz/rozciagasz kontrolke i juz! Wszystkie edytowalne properties oznaczone jako [Localizable] w metadanych podlegaja serializacji do .xx-yy.resx - .Image PictureBoxa - i dla oddzielnych kultur moga byc komplenie inne.

Mechanizm ten ma pewne ograniczenia. Główne i najważniejsze jest takie, że mechanizm jest super - czesc wartosci properties zrzuca do InitializeComponent - a w razie potrzeby rozszczepia wartosc na .resx ----- ale potrafi dostosowywac TYLKO (albo aż) serializowalne wartosci properties'ow. To znaczy, ze nie da rady przy jego pomocy stworzyc formatki, ktora w en-US bedzie miala 2 gridy, a w en-GB dwa listboxy zamiast nich. Ale da se to osiagnac na chama: dac dwa gridy, dac 2 listboxy, w en-US listboxom Enabled/Visible na false, w en-GB gridom..

@narzedzia - IMHO, Visual jest dobry do tego. programista przygotowuje forme z kontrolkami, potem tlumacz moze sie w visualu bawic, przesuwac, przelaczac jezyki itd. Ustawiac teksty, poprawiac uklad i rozmiary to sobie i nastolatek w designerze poradzi.. do edycji pozycji/rozmiaru innych narzedzi niz designer visuala sobie nie wyobrazam, ale moga istniec - ostatecznie 'pulpit edycyjny' designera to jest tez komponent i mozna go z VS wyciagnac i opakowac w boczne narzedzie tylko-do-edycji resx'ow.. Natomiast jest na pewno masa mikrotooli do edycji samych tekstow w resx'ach, wyswietalacych Ci np. tabelarycznie klucz-jezykA-jezykB-jezykC-... i pozwalajacych pozupelniac braki. Kiedys nie chcialo mi sie analogicznego tool'a szukac, wiec w ciagu 45minut z grida i system.blah.resxreader wysmazylem takie samemu.. czyli na sieci powinno byc z cwierc setki komercyjnych plus 6 opensource/darmowych :)

//edit. ostatnio sredni wordcount-per-post mi sie wydluza.. chyba nie mam z kim gadac i nadrabiam:}

quetzalcoatl napisał(a)

Po ustawieniu Localizable na 'true' nagle aktywuej sie Language i mozna sobie sybrac jezyk aktualnie edytowany. Uwaga: to oznacza, ze jedna formatka bedzie miala jeden glowny, domyslny wyglad, i N innych, zapisanych w .blah.xx-yy.resx. Jezeli wybierzecie jezyk Polski(PL), designer stworzy .pl-PLresx i bedziecie od tej pory poprzez designera edytowac tenze plik, a pozostale zostana bez zmian. Aby powrocic do edycji glownego wygladu, nalezy wybrac Language "puste", to z czubka listy.

Specjalnie napisalem domyslny wygląd a nie 'teksty'. Designerowa lokalizacja formatek pozwala nie tylko na podmiane tekstow. Jezeli przelaczyce sie na .de i przesuniecie button, przelaczycie sie na .pl -- button bedize w starej pozycji. Żadnego szlifowania rozmiaru/pozycji per-pixel w .pl-pl.resx! po porstu przelaczasz jezyk designera, przesuwasz/rozciagasz kontrolke i juz! Wszystkie edytowalne properties oznaczone jako [Localizable] w metadanych podlegaja serializacji do .xx-yy.resx - .Image PictureBoxa - i dla oddzielnych kultur moga byc komplenie inne.

Ale jaja. Nie wiedziałem. Dobre :)

p.s
Ale odradzam takie zabawy z designerem. Niestabilność designera Visual Studio jest załamująca. Właśnie mi się posypała cała formatka i nie mogę jej przywrócić. Używałem na formie kontrolek, które sam napisałem (normalnie działają bez błędu) i po włączeniu lokalizacji i małej zmianie wyglądu formatki wszystko się posypało i zgłupiało. Tragedia.

Instances of this error (1)

1. Hide Call Stack

at System.Windows.Forms.Control.AssignParent(Control value)
at System.Windows.Forms.DataGridView.AssignParent(Control value)
at System.Windows.Forms.Control.ControlCollection.Add(Control value)
at System.Windows.Forms.TabPage.TabPageControlCollection.Add(Control value)
at System.Windows.Forms.Design.ControlDesigner.DesignerControlCollection.Add(Control c)

Niestabilność designera Visual Studio jest załamująca.

Nie rozumiem... Mi się jeszcze ani razu nie posypał...

Używałem na formie kontrolek, które sam napisałem (normalnie działają bez błędu)

Call stack który podałeś wskazuje na błąd w System.Windows.Forms...
Jeśli byś mógł to podaj trochę więcej informacji.

Zrobiłem tak jak mówiłeś. Później w zlokalizowanej, polskiej wersji formatki zmieniłem tekst jednej labelki. I to był początek końca. Po prostu się posypało i tyle. Nie mogę nic z tym zrobić. W Delphi jest to lepiej rozwiązane. A tu same problemy z designerem.

Zdaje się, że pisałem Ci już dawno temu na innym forum, żebyś pisał w takim razie w Delphi.

Designer Winformsowy ma pewne nieraz głupie i frustrujące ograniczenia, potrafi się też okazjonalnie sypnąć. Niemniej jednak jeśli dzieje się coś permanentnie, to raczej wina programisty, który próbuje osiągnąć coś niedozwolonego.

Człowieku przestań. Tu nie chodzi o jakieś głupie idee. Po prostu się sypnęło i tyle. Nie zrobiłem niczego niedozwolonego. Nie grzebałem po kodzie designera. Zrobiłem to co powinno było zadziałać, ale nie zadziałało. Błąd programistów Microsoft. Sypnęło się i koniec bajki. Teraz trzeba szukać kopii zapasowej.

1. każdy normalny czlowiek piszący kod używa jakiegos SCM'a jak CVS, SVN, HG lub czegos mu podobnego. sam sobie jestes winien

2. narzedzia maja prawo sie sypac. to tylko narzedzia, pisane przez ludzi. sprobuj sobie pouzywac Eclipse'a sprzed 3-4 lat - a jest to jedno z najbardziej znanych srodowisk. i z racji praw Murphy'ego, sypia sie wtedy, kiedy probujesz czegos nowego - bo tego nie znasz i nie wiesz jak uzywac. ergo, sam jestes sobie winien, ze nie zrobiles przed probami kopii .designer.cs i resxow. nie eksperymentuje sie na jedynej rzeczy jaka sie posiada.

3) w vs2005-2008 obsluga .designer.cs oraz resx jest bardzo dobra i sypie sie rzadko. jezeli uzywasz vs2010 beta, to jest ona spierdo-ehem na maksa i nie potrafi nawet poprawnie obsluzyc roundtripa pliku .designer.cs. jesli uzywasz darmowki vs2010, sam jestes sobie winien - to jest beta. [tak, wiem ze uzywasz VS2008. wyboldowalem to jako ostrzezenie dla innych. Ciebie czeka opernicz w punkcie 5tym]

Ale odradzam takie zabawy z designerem. Niestabilność designera Visual Studio jest załamująca. Właśnie mi się posypała cała formatka i nie mogę jej przywrócić.
'nie mogę' to nie to samo co 'nie potrafię'. wiesz, nawet jak sie DS wysypie, to dopoki nie nacisniesz ctrl+s, plik wystarczy ze zamkniesz i otworzysz jeszcze raz? s-j-s-w.

Używałem na formie kontrolek, które sam napisałem (normalnie działają bez błędu) i po włączeniu lokalizacji i małej zmianie wyglądu formatki wszystko się posypało i zgłupiało. Tragedia
to znaczy, i biorac pod uwage, ze designer sie wysypal, ze NIEPRAWIDLOWO napisales swoje kontrolki. jezeli sa to dziedziczcae po usercontrol, mala szansa ze tak jest, ale jesli masz je w sobie pozagniezdzane powyzej 1 poziomu -- to to jest bardzo prawdopodobne. serio. napisac poprawna kontrolke, ktora bedzie bezpiecznie zachywac sie w normal oraz w design mode, jest ciezko. s-j-s-w. a jako ze pisywales jak widac wlasne kontrolki i doswiadczyles wczesniej niestabilnosci designera -- spowodowanej Twoimi wadliwymi kontrolkami -- to s-j-s-w^3, poniewaz powinienes wiedziec ze designer Twoich kontrolek jest uszkodzony i odruchowo pierwsza rzecza jaka powinienes byl zrobic przed wlaczeniem uszkodzonego-twoimi-kontrolkami designera, powinno byc skopiowanie designer.cs albo initializecomponent..
od pewnego czasu staram sie intencjonalnie pisac kontrolki i komponenty tak, aby moc >80% procent rzeczy powtarzalnych zrobic poprzez designera, gwarantuje Ci, ze designer zachowuje sie deterministycznie. 100%-1e-4 bledow lezy w Twoim/moim/yimś jego nie zrozumieniu, nie zrozumieniu cyklu zycia rzeczy (np. ze designer tworzy i faktycznie uzywa kodu Twoich kontrolek, ale nie calego, albo ze korzysta zawsze z NIEaktualnych wersji pochodzacych z kompilacji jedna-wczesniej. kompilacji jawnej lub nie, do swojego cichego katalogu na tymczasowe kontrolki) i roznic miedzy design/normal, albo po prostu w blednym kodzie kontrolek, ktore testowales w pracujacej skompilowanej aplikacji, ale NIE PRZETESTOWALES ich w designmode i sadzisz ze "no przeciez dzialaja wiec czemu mialy by nie dzialac" i sie dziwisz ze cholera, nie dzialaja..

Sorry, ale wkurzylo mnie Twoje biadolenie/indolencja/ignorancja/brak samokrytyki/pisanie na kozaka bez SCM'a. A co jezeli bys przypadkiem sie oparl ręka na klawiaturze i by Ci sie wcisnelo w designerze ctrl-A, delete, ctrl-S? tez Visual i Microsoft bylby glupi, a nie że Ty sie z tym zle obchodzisz? d'oh!!

BorysBe napisał(a)

Człowieku przestań. Tu nie chodzi o jakieś głupie idee.

Założyłeś wątek w dziale o .NET szukając rozwiązania dość standardowego problemu okrężną drogą, a gdy coś Ci się nie udało, piszesz, że M$ jest zły a Delphi wspaniałe.
To raczej nie ma związku z problemem, nie ma żadnego znaczenia dla Twojego sytuacji (no chyba, że możesz zmienić technologię), jest po postu marudzeniem i szerzeniem jakichś idei. ;)

Błąd programistów Microsoft. Sypnęło się i koniec bajki.

Może i tak. Ale czemu Ty miałbyś być tym wybrańcem, któremu nie działa obsługa lokalizowania kontrolek? ;)

Designer może się sypnąć z wielu powodów, np:

• nieskompilowane/stara wersja kodu, który jest wołany;
• bindindowanie do nieistniejących klas;
• inny niepoprawny kod w InitializeComponent;
• próby ładowania danych w konstruktorze;
• wyjątki rzucane gdzieś w konstruktorze bazowej formatki/kontrolki;
• abstrakcyjna klasa bazowa formatki/kontrolki (to akurat czysty debilizm :|)
• pewno jeszcze inne...

Ja w takiej sytuacji sprawdzam to wszystko i jakoś zawsze wychodzi na to, że to jednak moja wina, a nie producenta. To jednak M$ a nie gimnazjaliści od Opery.

BTW: WTF is "s-j-s-w"?

quetzalcoatl napisał(a)

1. każdy normalny czlowiek piszący kod używa jakiegos SCM'a jak CVS, SVN, HG lub czegos mu podobnego. sam sobie jestes winien

Człowieku, jesteś moderatorem, więc powinieneś trzymać poziom - wyluzuj się trochę zanim zaczniesz oceniać kogoś. Nie używałem SVN-a, bo za dużo robiłem zmian - choćby w nazwach plików, kontrolek, nazwach projektów - po to by to wszystko ładnie było zaprojektowane. Wciąż jestem na etapie projektowania architektury aplikacji. SVN by zgłupiał od ciągłych zmian i usuwania plików - i jaki miałbym z niego pożytek? Dlatego wolałem robić kopie zapasowe w postaci *.zip-ów. Dlaczego to Cię boli?

quetzalcoatl napisał(a)

2. narzedzia maja prawo sie sypac. to tylko narzedzia, pisane przez ludzi.

A użytkownicy mają prawo narzekać. Mają do tego bardziej prawo niż narzędzia mają prawo się sypać. Tak?

quetzalcoatl napisał(a)

sprobuj sobie pouzywac Eclipse'a sprzed 3-4 lat - a jest to jedno z najbardziej znanych srodowisk. i z racji praw Murphy'ego, sypia sie wtedy, kiedy probujesz czegos nowego - bo tego nie znasz i nie wiesz jak uzywac. ergo, sam jestes sobie winien, ze nie zrobiles przed probami kopii .designer.cs i resxow. nie eksperymentuje sie na jedynej rzeczy jaka sie posiada.

Eclipse mnie załamuje nawet dzisiaj, więc potrafię sobie wyobrazić go 3-4 lata temu. Zresztą... zaraz, zaraz... 2007 rok, tak? pamiętam te beznamiętnie zachwycone gęby, gdy ja w 2007 narzekałem na Eclipse.

Gdzie ja Ci powiedziałem, że to była jedyna kopia jaką posiadałem?

quetzalcoatl napisał(a)

3. w vs2005-2008 obsluga .designer.cs oraz resx jest bardzo dobra i sypie sie rzadko.

Kpisz sobie ze mnie? Jakby była tak dobra jak tego chcę, to by się nie sypało wcale. Ile milionów dolarów w to poszło? Chyba mam prawo żądać jakości. Nie rozczulaj się tak nad Microsoftem.

quetzalcoatl napisał(a)

'nie mogę' to nie to samo co 'nie potrafię'. wiesz, nawet jak sie DS wysypie, to dopoki nie nacisniesz ctrl+s, plik wystarczy ze zamkniesz i otworzysz jeszcze raz? s-j-s-w.

No właśnie, tak to powinno być - ale tak wcale nie zadziałało gdy się posypało cholewa.

Bardzo dokładnie testuje kontrolki - zarówno w design mode jak i podczas normalnego cyklu życia aplikacji. Tak ze mną rozmawiasz jakbyś miał pewność, że piszesz swoje własne kontrolki lepiej i chciał się wywyższać. Jednak ani to ładnie, ani nie masz tej pewności, że je piszesz bardziej profesjonalnie ode mnie. Tym bardziej ja jej nie mam, więc zanim zaczniesz kogoś krytykować zastanów się dwa razy. Tak się składa, że nie od wczoraj tworzę kontrolki i nie tylko w C#. Więc mam jakieś pojęcie.

To ja powiedziałem pierwszy - że to pewnie przez to, że używam moich własnych kontrolek posypało się Visual Studio, a Ty sam powiedziałeś że to nie kontrolki tylko posypało się WinForms, bo call stack wskazuje na to. Zdecyduj się w końcu.

BTW. Już sobie przywróciłem kopię zapasową.

Przy okazji nie dyskredytuję Ciebie ani Twojej wiedzy, ale uważam, że byłeś trochę niegrzeczny w stosunku do mnie w swoim ostatnim poście.

somekind napisał(a)

Założyłeś wątek w dziale o .NET szukając rozwiązania dość standardowego problemu okrężną drogą, a gdy coś Ci się nie udało, piszesz, że M$ jest zły a Delphi wspaniałe.
To raczej nie ma związku z problemem, nie ma żadnego znaczenia dla Twojego sytuacji (no chyba, że możesz zmienić technologię), jest po postu marudzeniem i szerzeniem jakichś idei. ;)

No w sumie masz racje. Chyba lubię marudzić.

Może i tak. Ale czemu Ty miałbyś być tym wybrańcem, któremu nie działa obsługa lokalizowania kontrolek? ;)

A dlaczego tak często psuje się autobus/pociąg którym akurat ja jadę? Byłem wybrańcem i tyle :)

BorysBe napisał(a)

Dlatego wolałem robić kopie zapasowe w postaci *.zip-ów.

Z ciekawości - robiłeś je ręcznie czy jakąś wtyczką?

A propos wtyczek - masz zainstalowane jakieś nietypowe dodatki? Bo przez nie VS potrafi niestabilnie działać.

Ile milionów dolarów w to poszło? Chyba mam prawo żądać jakości.

No niby tak - pod warunkiem, że Ty te miliony dolarów zapłaciłeś i masz z nimi umowę o dzieło na bezbłędnie napisane IDE. ;)
A jeśli nie, to chyba pozostaje Ci to co każdemu - zgłosić im buga.
(BTW: Wiadomo, że na działanie zakupionego oprogramowania można narzekać. Ale czy na soft z MSDNAA także? W końcu jest za darmo.)

uważam, że byłeś trochę niegrzeczny w stosunku do mnie w swoim ostatnim poście.

Poczytaj lepiej inne jego posty. ;)

Człowieku, jesteś moderatorem, więc powinieneś trzymać poziom
Nie będę się tym razem rozpisywać, gdyż zawarlem komplet w poprzednim poście, łącznie z przeprosinami pod koniec jeśli by Cie cos uraziło, acz nie wiem co - bo poza "s-j-w-s" ktore fakt byly za ostre, reszta IMHO "poziom trzyma", dziekuje za uwagę. Odpowiadam więc tylko na nowe pytania..

Dlaczego to Cię boli?
ad persona, pomijam

SVN by zgłupiał od ciągłych zmian i usuwania plików
jeszcze mi sie to nie zdarzylo.. przy cvs i vss - tak, przy svn, hg - nigdy.. żeby było ciekawiej, staram sie uzywac scm'a od samego poczatku, wlasnie po to abym nie musial robic zipow, szukac ich, etc. svn+tortoise swietnie to zastepuje, dajac dodatkowo diffy, merge, etc etc. delete/rename/move - rightmousedrag i już.. nie widze problemu!

No właśnie, tak to powinno być - ale tak wcale nie zadziałało gdy się posypało cholewa. Bardzo dokładnie testuje kontrolki - zarówno w design mode jak i podczas normalnego cyklu życia aplikacji. Tak ze mną rozmawiasz jakbyś miał pewność, że piszesz swoje własne kontrolki lepiej i chciał się wywyższać
nie wierze, ze designer nadpisal Ci plik.. żebym nie wiem jak bardzo miał uszkodzoną swoja kontrolkę, dopoki kodu nie przekompiluje albo nie walne save/all, pliki - takze designer.cs - nie nadpisuja mi sie.. nie, nie wywyzszam sie - po co mi to - zaznaczylem po prostu ilosc bledow, podstawowych, jakie mozna popelnic piszac wlasny komponent. jesli czulbym sie wyzej i bylbym ekspertem, odeslalbym Cie do dokumentacji na msdn zamiast probowac wskazac zrodla bledow na ktore ja sam ciagle wpadam.. mam natomiast kompletna pewnosc, ze zeby jakas kontrolke - bardziej skomplikowana niz tutorialowe pozlepianie paru gotowych kontrolek - napisac dobrze, trzeba spedzic czasem i paredziesiat godzin, poniewaz z poziomu visuala support dla tesotwania i debugowania jest praktycznie zaden, a i dokumentacja jasnoscia nie cieszy. zwlaszcza jesli wziac pod uwage trojakosc poziomow na jakich VS udostepnia Ci swoje design-time-api czy jak oni to tam zwą.. osobiscie juz wiele razy bylem pewien ze mam komponent z designtimem doszlifowany i po 2-3 miesiacach wychodzilo cos jeszcze, zawsze blad u mnie, acz 2 (dwa) razy spowodowane bledem/niespojnoscia api visuala/.neta

Kpisz sobie ze mnie? Jakby była tak dobra jak tego chcę, to by się nie sypało wcale. Ile milionów dolarów w to poszło?
nie kpię. poszło mało i naprawde braki stabilnosci sa powodowane extrasami a nie nim samym. pieniadze poszly na większość funkcjonalności VS, tej z punktu widzenia klepacza kodu. na support dla tworzenia wlasnych komponentow (przy czym pozwole sobie podkreslic, ze mam na mysli bardziej skomplikowane komponenty niz usercontrol plus kilka basecontrols) pieniadze nie poszly, poniewaz jest to temat dla firm-dostawcow bibliotek, a nie temat dla szarego programisty. za mozliwosc pobawienia sie w pisywanie komponentow z designtimem (ktore maja wlasne designery/etc) -- do nie dawna, a moze i wciaz, trzeba bylo placic za dostep do VSIP.. smiem twierdzic, ze to z czego ja i Ty korzystamy, to nie VSIP tylko rzeczy publiczne, i one sa niedopracowane - bo nie na to ida pieniadze.. w vs2008 sporo jednak poprawiono. moze przy vs2010 i shellu w xamlu bedize bezpieczniej, wcale by mnie to nie zdziwilo, gdyz MS dazy do tego i juz ktorys az probuje jak najbardziej odciac GUI od reszty, miedzy innymi, poza wodotryskami graficznymi, wlasnie dlatego zeby designer byl bardziej hm.. zabunkrowany i odseparowany od faktycznego kodu pisanego przez programiste

To ja powiedziałem pierwszy - że to pewnie przez to, że używam moich własnych kontrolek posypało się Visual Studio, a Ty sam powiedziałeś że to nie kontrolki tylko posypało się WinForms, bo call stack wskazuje na to. Zdecyduj się w końcu.
przeczytalem posty jeszcze raz - nie tak to ujales, ani ja tak nie powiedzialem. powiedzialem ze "wysypal sie designer", czyli ogolnie roundtrip .designer.cs->deserializacja->drzewokontrolek->modyfikacja->serializacja ->.designer.cs. nie musze sie tez decydowac, poniewaz jesli blad byl w Twojej kontrolce, to nawet i WinForms moglby sie sypnac, nie mowiac o kruchej serializacji drzewa kontrolek do pliku .designer.cs/resx.. jeden z wielkich bóli crashow kontolek pod designerem jest taki, ze stacktrace'y nie wiele tutaj mówia, wrecz nawet jestem sklonny powiedziec, ze raporterbłędow przycina je nieprawidłowo. czesto, tylko podpiecie drugiego visuala i przebadanie sprawy na zywo + reflector/sourceserver + kilka godzin potrafią rozstrzygnac gdzie tak naprawde lezy blad - i czy jest Twoj, czy Formsow/ShellaVS, bo i takie sie zdarzaja..

Niemniej, zgadzam sie, że chandryczenie sie daleko nie zaprowadzi nikogo, tak jak i wyliczanie sobie kto ile czego i jak dobrze napisał. Jezeli miałbys ochotę przeduskytować konstrukcję kontrolek i szukać co naprawdę wtesy wywaliło designera - ja bardzo chętnie się piszę, jednak musiałbyś rzucic kompletem kodu.

edit: zauwazylem blad w kolejnosci cytowan, teraz chyba jest sensowniej

Właściwie włączyłem localizable i zmieniłem język. Wszystko działało. Skompilowałem program. Wszystko wciąż działało.

Później chciałem zmienić wygląd jednej kontrolki na określonym języku. I wtedy wszystko się posypało. Mało tego, jak otworzyłem ponownie Visual Studio to mimo, że wcześniej foma działała, to po restarcie środowiska już przestała - a pliku nie dało się przywrócić, bo się zapisał, choć nie naciskałem Ctrl+S. Dlatego się trochę poirytowałem i dałem edit do posta, może niepotrzebnie dałem się ponieść chwilowym emocjom, to fakt. Co do SVN-a to robię dużo zmian w nazwach pliku z poziomu Visual Studio, przenoszenia plików między projektami, żeby lepiej zorganizować pracę. Czy SVN by nie zgłupiał od tego?

nie wierze, ze designer nadpisal Ci plik.. żebym nie wiem jak bardzo miał uszkodzoną swoja kontrolkę, dopoki kodu nie przekompiluje albo nie walne save/all, pliki - takze designer.cs - nie nadpisuja mi sie.. nie, nie wywyzszam sie - po co mi to - zaznaczylem po prostu ilosc bledow, podstawowych, jakie mozna popelnic piszac wlasny komponent. jesli czulbym sie wyzej i bylbym ekspertem, odeslalbym Cie do dokumentacji na msdn zamiast probowac wskazac zrodla bledow na ktore ja sam ciagle wpadam.. mam natomiast kompletna pewnosc, ze zeby jakas kontrolke - bardziej skomplikowana niz tutorialowe pozlepianie paru gotowych kontrolek - napisac dobrze, trzeba spedzic czasem i paredziesiat godzin, poniewaz z poziomu visuala support dla tesotwania i debugowania jest praktycznie zaden, a i dokumentacja jasnoscia nie cieszy. zwlaszcza jesli wziac pod uwage trojakosc poziomow na jakich VS udostepnia Ci swoje design-time-api czy jak oni to tam zwą.. osobiscie juz wiele razy bylem pewien ze mam komponent z designtimem doszlifowany i po 2-3 miesiacach wychodzilo cos jeszcze, zawsze blad u mnie, acz 2 (dwa) razy spowodowane bledem/niespojnoscia api visuala/.neta

Narzekałem na stabilność designera, gdyż bardzo dużo czasu w ostatnich latach poświęciłem na pisanie kontrolek i designer wykrzaczał mi się setki razy. Zazwyczaj wina mojego kodu, ale uważam, że ten designer mógłby być bardziej idioto-odporny :) Np. miałem dwa razy taką sytuacje, gdy przez zwykłą literówkę w kodzie property Visual wpadał w nieskończoną pętle - a mógłby przecież ostrzec użytkownika, że ten robi idiotyczne rzeczy zanim designer puści nieskończoną rekurencje. Miałem też wiele okazji zaobserwować różne inne rzeczy i powiem szczerze, moja lista życzeń i rozczarowań wobec designera bardzo się wydłużyła. Pewno jestem zbyt wyczulony, ale jakoś nie pałam zachwytem nad tym jak to jest rozwiązane w VS. Zgadzam się zaś, że pisanie bardziej skomplikowanych kontrolek nie jest wcale takie łatwe.</quote>