I nastał ten dzień. Dzień długo wyczekiwany przez wszystkich miłośników Windows Phone 7. Całe 7% użytkowników smartfonów przebierało nogami. Pojawiła się oficjalna aktualizacja systemu do wersji 7.1.

Postanowiłem zasmakować tego zakazanego owocu. Punktem wyjścia był telefon LG E900 aka Optimus 7 aka Swift 7 z systemem w wersji Nodo (7.0.3792). Podłączyłem ustrojstwo do komputera, odpalił się Zune i znalazł… aktualizację do wersji 7.0.7403. „Pewnie jakieś porządki po wersji beta to będzie robić” – mówię sobie. Instaluje. Zainstalowałem. Odświeżenie …. i jest. Dostępna aktualizacja telefonu do wersji 7.10.7720.68. Jest… MANGO!!!

Instaluje… instaluje… długo… błąd, James Błąd. A imię jego 8018001E. Google. Google prawdę Ci powie. Cała masa użytkowników LG ma ten sam problem. Chwila czytania i okazuje się, że szczęśliwcy, którym aktualizacja nie wyszła to posiadacze telefonów, które nie pochodzą od operatorów, tylko z „wolnej” dystrybucji. Dodatkowo tyczy się to tylko tych z oprogramowaniem (firmware) w wersji 1.0.1.12. Krótkie sprawdzenie – tak jestem jednym z nich.

Okazuje się, że dawno dawno temu operatorzy wprowadzili do obrotu odpowiednie poprawki, natomiast LG samo w sobie nie wypuściło aktualizacji dla tych bez cyrografów. Bajka – uwielbiam to. Google. Nie ma nigdzie do ściągnięcia aktualizacji. I co teraz? Lipa.

Po chwili olśnienie – na XDA Develoeprs dostępne jest oryginalne oprogramowanie do LG E900. Może da rade. Procedura nie jest banalna, ale co tam. Ściągnąłem oprogramowanie dla polski oraz wszystkie inne potrzebne narzędzia. W tym miejscu nadmienię, że różnicy między POLAND a EUROPE OPEN nie ma wielkiej – o wszystkim za chwilę.

Zanim przejdę dalej – spójrzcie proszę na sam koniec wpisu!

Postępuję zgodnie krokami. Modem się nie chce zainstalować po podłączeniu telefonu. Aaaa trzeba uruchomić telefon w trybie awaryjnym (przycisk aparatu + głośność w dół + zasilanie) i dopiero podłączyć do kompa. Instalują się sterowniki…. ale nie chcą się skończyć instalować. Odłączam telefon – zainstalowano – dziwne? Podłączam ponownie. Wykryty, zainstalowany. Krótka kontrola w menedżerze urządzeń upewnia mnie – jest modem na porcie COM4.

Odłączam telefon. Odpalam LGDP2_V36_UMTS z uprawnieniami administratora (Uruchom jako) – o tym nie wspomniano. Wczytuję DLLkę, plik z firmware, zaznaczam COM4 (nie zaznaczam USB mode). Po potwierdzeniu wyskakuje błąd o braku możliwości odnalezieniu monitora portu. Ignoruje Wciskam Start i dopiero teraz podłączam telefon (cały czas będący w trybie awaryjnym). Chwila napięcia… i tak wgrywa się… wgrywa. Całość trwa parę minutek, ale kończy się sukcesem Mam świeżutki telefon w wersji 7.0.7004 z firmware w wersji 1.1.2.10 – może teraz zjem Mango.

W tym momencie, aby nie ciągnąć zbyt długo – oczywiście po dojściu do końca aktualizacji okazuję się, że po języku polskim w interfejsie nie ma śladu. Po zakończeniu aktualizacji do Mango nie ma możliwości dogrania języka. Aby w efekcie go uzyskać należy zrobić co następuje.

Korzystamy z dobrodziejstwa LG, które dało w gratisie aplikacje diagnostyczną, która pozwala grzebać w rejestrze. Aby do niej się dobrać uruchamiam telefon i wybieram ##634# i dzwonię… dodzwoniłem się, ale pytają i hasło. Znam 277634#*#. Wybieram Engineer Menu, Other Setting, Edit registry.

Jako ROOT_PATH wybieram HKEY_LOCAL_MACHINE, jako SUB_PATH wpisuję MUI\Available.

Muszę teraz dodać klucz o nazwie będącej kodem języka w formie szesnastkowej i wartości (łańcuch znaków) odpowiadającej nazwie języka.

Potrzebujemy kod języka polskiego – z pomocą przychodzi nam tabela na stronie Microsoftu – 0415 – wpisuję to jako KEY, a jako data Polish. Nie wiem, czy nazwa jest istotna, ale na wszelki wypadek tak sobie wpiszę. Można zapewne dopisać inne języki z listy 25 nowych dostępnych w Mano, ale nie sprawdzam.

Klikam Set i Query dla upewnienia się, że zapisałem. Git Podłączam do Zune, aktualizacja…. kończy się wersją 7008. No to teraz NoDo… ale co to? Zune nie wykrywa aktualizacji. Damn… Google. Super hiper łopatologiczny sposób.

Wyłączam w telefonie WiFi oraz transmisje danych poprzez sieć komórkową. Podłączam telefon do komputera. W Zune wybieram „aktualizacja”… wyszukiwanie aktualizacji, po ok 3 sekundach „wyszukiwania” odłączam komputer od sieci (albo brutalnie kabelkiem albo jak mi się nie chce to wyłączam połączenie sieciowe). Zune znalazł aktualizację do 7392. Jupi. (Nie za pierwszym razem się udało, ale wyczułem moment ) Włączam sieć, klikam „Aktualizuj”. Czekam na koniec…. jest!

Teraz powinna być 7403… ale też jej nie ma. Powtarzam manewr – jest. Aktualizuję. Gotowe – jest 7403. Szukam Mango – błąd połączenia. Jeszcze raz. Jest – aktualizacja dostępna! Aktualizuję….. zrobione. Tak, jest, mam mango 7.10…. Wchodzę w ustawienia, język wyświetlania – tak jest Polski Wybieram, ciesze się jak dziecko.

I tym oto prostym sposobem mogę cieszyć się LG E900 z Mango i pełną polonizacją. Tylko dlaczego do cholery nadal nie mogę po prostu wysłać sobie zdjęcia przez Bluetooth… dlaczego nie mam dostępu do wszystkich aplikacji w markecie (no ale już mam dostęp z polskiego konta live do marketu i xbox – postęp)…  ale to być może historia na inny wpis

Aha – nie muszę chyba wspominać, że cała procedura sprowadza się do tego, że w telefonie nie pozostanie ślad po ustawieniach, plikach…

Dziś krótki artykuł z cyklu „małe a cieszy”

Chyba każdy programista w trakcie swojego życia zbiera jakieś przydatne kawałki kodu. Niektórzy tworzą z nich drobne biblioteki, inni całe frameworki. To czy jest to praktyka zła, czy dobra nie jest tematem tej rozprawki. Wszystkim nam gdzieś tam jednak przyświeca idea DRY (Do not Repeat Yourself). Jak ją sobie zrealizujemy, to już zależy od nas. Przynajmniej w naszych prywatnych projektach. Z owymi „przydasiami” wiąże się pewien problem. Gdy już stworzymy sobie szereg bibliotek, chcielibyśmy je wykorzystać w różnych projektach.

Osobiście przeszedłem przez etap repozytorium binarek trzymanych w SVN, sciąganych do wyznaczonego katalogu; ręcznego dodawania do nich referencji; czy tworzenia instalatorów WiX, które pakowały binarki do GAC oraz do katalogu z „referencyjnymi bibliotekami”. Miało to tyle wad co zalet, a rozwiązanie z WiXem było dodatkowo pracochłonne.

Na szczęście na horyzoncie pojawił się NuGet.

O tym, czym NuGet jest, chyba nikomu ze światka około .NETowego mówić nie muszę. Gdyby jednak ktoś nie kojarzył, odsyłam na oficjalną stronę projektu, gdzie możecie w szczegółach zaznajomić się z projektem.

W wielkim skrócie to narzędzie, które korzystając ze zdefiniowanych repozytoriów, potrafi dodać do projektu niezbędne referencje, uprzednio ściągając wszystkie potrzebne pliki. Potrafi także wprowadzić zmiany w konfiguracji i wiele, wiele innych fajnych rzeczy. A to wszystko możemy zrobić z poziomu menu kontekstowego w Visual Studio. Bajka!

Myśl, która automatycznie przychodzi do głowy to: „ja chcę takie repozytorium; będę mógł publikować paczuszki, z których będę później korzysał w różnych projektach, a nawet będe mógł się nimi podzielić ze współpracownikami.”.

Istnieje publiczne repozytorium NuGet, ale z pewnością nie chcemy tam umieszczać prywatnych rzeczy (przynajmniej do czasu kiedy zdecydujemy się opublikować wyniki naszej ciężkiej pracy).

Dostępne rozwiązania hostujące repozytoria działają tylko na platformie Windows, a hosting Windowsowy do najtańszych nie należy. Własnego rozwiązania w np. PHP pisać nam sie nie chce. Jak więc sobie z tym poradzić? Dzięki temu, że ktoś wykonał kawałek dobrej roboty i pomyślał, repozytorium NuGet możemy mieć w postaci katalogu z paczkami .nupkg.

Takie repozytorium możemy synchronizować za pomocą Git dla przykładu.

Zanim przystąpimy do pracy musimy zaopatrzyć się w potrzebne narzędzia. Poza instalacja rozszerzenia NuGet do Visual Studio 2010, które począwszy od dodatku Service Pack 1 zainstalowane jest domyślnie, musimy zaopatrzyć się w narzędzie linii poleceń dostepne na stronie projektu, które przyda się do tworzenia paczek.

Zatem do dzieła – stwórzmy i skonfigurujmy repozytorium. Zakładam, że nasze repozytiurm będzie współdzielone pomiędzy kilka osób, zatem gdzieś na dedykowanym serwerze tworzymy puste, współdzielone repozytorium (ja posiłkuję się po stronie serwerowej technologią okołopingwinową, więc takiej będę się tu trzymał). Dla ustalenia uwagi przyjmijmy, że lokalnie repozytorium będzie znajdować się w katalogu D:\Packages. Na serwerze, gdzie hostujemy repozytoria, tworzymy nowe, a następnie klonujemy do wspomnianego katalogu. Katalog ten następnie dodajemy w Visual Studio:

Dodajemy nowe repozytorium wprowadzając nazwę oraz lokalizację na dysku lokalnym:

Repozytorium skonfigurowane. Pozostaje tylko je czymś wypełnić.

Zanim przystąpimy do tworzenia biblioteki musimy wykonać dwa kroki wstępne:

• Do zmiennej systemowej PATH dodać scieżkę do sciągniętego uprzednio pliku NuGet.exe
• Zdefiniować zmienna systemowa PACKAGESDIR (dla przykładu), która będzie wskazywać katalog docelowy na tworzone paczki.

cd $(ProjectDir)

NuGet.exe pack $(ProjectFileName) -OutputDirectory $(PACKAGESDIR) -Properties Configuration=Release

W pliku AssemblyInfo.cs dodajemy co najmniej takie atrybuty:

[assembly: AssemblyTitle("SampleLibrary")]
[assembly: AssemblyDescription("SampleLibrary")]
[assembly: AssemblyCompany("ACME")]
[assembly: AssemblyProduct("SampleLibrary")]
[assembly: AssemblyCopyright("Copyright © ACME 2011")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

Po zapisaniu zmian i przekompilowaniu projektu, w katalogu D:\Packages pojawi się nowa paczka. W powyższym przykładzie opis paczki oraz podstawowe informacje o niej pobierane są z pliku projektu. Jeżeli zależy nam na większej kontroli, możemy utworzyć dla projektu plik .nuspec z dokładną specyfikacją paczki. Szczegóły formatu znajdziecie w dokumentacji projektu NuGet.

Po poprawnej kompilacji możemy zweryfikować, czy paczka jest dostępna. Z menu kontekstowego gałęzi References wybieramy opcję umożliwiającą dodanie referencji do paczki:

Jak widać na załączonym obrazku, nowo utworzona paczka jest gotowa do instalacji:

Pamiętajmy, aby po utworzeniu paczek zsynchronizować repozytorium Git. Inni niech też coś z tego mają

Jeżeli paczki w repozytorium odświeżają się częściej niż ich numery wersji, istnieje konieczność ich ponownego pobrania. Z pudełka nie dostajemy obecnie nic, co by mogło nam w tym pomóc. Po chwili googlania możemy jednak znaleźć potrzebne narzędzie.

Przedstawione rozwiązanie to najprostszy przypadek jaki można sobie wyobrazić. NuGet posiada wiele opcji, z których można skorzystać, aby utworzyć paczki dostosowane do własnych potrzeb. Zachęcam do zagłębienia się w szczegóły. Naprawdę warto!

Przyznam szczerze, że dotychczas z komunikacją między różnymi aplikacjami lub ich warstwami spotykałem się głownie w aspekcie usługowo-webowym. Taki scenariusz sprowadza się do takiego a nie innego wykorzystania webservice lub pochodnego ustrojstwa. Co jednak można zastosować jeżeli chcemy aby dwie nasze aplikacje miały możliwość pogadania ze sobą na lokalnej maszynie?

Rozwiązań jest sporo albo i jeszcze więcej. Poczynając od SendMessage z Win32 API, współdzielonej pamięci, webservice, TCP,  COM, DCOM na named pipes kończąc. Jednak chcemy czegoś prostego w implementacji, w końcu programiści są leniwi (w pozytywnym tego słowa znaczeniu ). Postaram się przedstawić dwa scenariusze, z których jeden należy od razu wyeliminować jako obsolete – jednak jako ciekawostkę przytoczę. A drugim będzie WCF – i tą cześć można potraktować jako swoisty quickstart do tej technologii. Mimo że to już nic nowego miałem wenę, aby o tym napisać

Dla ustalenia uwagi przyjmiemy scenariusz, w którym aplikacja A (Host) będzie świadczyć usługi na rzecz aplikacji B (Client), które to sprowadzą się do prostej operacji na łańcuchu znaków i równie prostej operacji pobrania jakiejś paczuszki, która będzie typem nieco bardziej skomplikowanym.

Dawno, dawno temu jak jeszcze .NET miał 1 w numerze wersji istniała technologia .NET Remoting. Ustrojstwo które przypomina w użyciu nieco technologię COM, a obecnie jest niezalecane przez Microsoft na rzecz WCF.

Rzeczą numer jeden jest umowa stanowiąca co oferuje host. Umowę taką definiujemy w postaci kontraktu – interfejsu. Na potrzeby .NET Remoting wystarczy zdefiniować interfejs taki jak na załączonym obrazku:

namespace Contracts
{
    public interface ISampleService
    {
        string ProcessMessage(string message);
        Payload GetPayload();
    }
    [Serializable]
    public class Payload
    {
        public DateTime TimeStamp { get; set; }
        public int Value { get; set; }
        public Payload()
        {
            TimeStamp = DateTime.Now;
            Value = (new Random()).Next();
        }
        public override string ToString()
        {
            return String.Format("{0};{1}", TimeStamp, Value);
        }
    }
}

Ponieważ Payload jak widać jest paczuszką, która będzie przesyłana między procesami, musi istnieć możliwość jej serializacji – oto tajemnica atrybutu [Serializable].

Niezwykle skomplikowany kod Hosta wygląda następująco:

namespace RemotingHost
{
    class Program
    {
        static void Main(string[] args)
        {
            var channel = new IpcChannel("RemotingHostChannel");
            var serviceType = typeof(SampleService);
            ChannelServices.RegisterChannel(channel, false);
            RemotingConfiguration.RegisterWellKnownServiceType(serviceType,
                "SampleService",
                WellKnownObjectMode.Singleton);
            Console.WriteLine("Host is running, hit <RETURN> to stop...");
            Console.ReadLine();
        }
    }
    public class SampleService : MarshalByRefObject, ISampleService
    {
        #region ISampleService Members
        public string ProcessMessage(string message)
        {
            int processID = Process.GetCurrentProcess().Id;
            Console.WriteLine("{1}: Recieved message: {0}", message, processID);
            return String.Format("{1}: your input is \"{0}\"",
                                 message, processID);
        }
        public Payload GetPayload()
        {
            int processID = Process.GetCurrentProcess().Id;
            var result = new Payload();
            Console.WriteLine("{0}: generated payload {1}", processID, result);
            return result;
        }
        #endregion
    }
}

Kilka linijek na krzyż i mamy już kawałek aplikacji, która umie świadczyć wybrane usługi klientom. Jako parametr konstruktora klasy IpcChannel podaliśmy nazwę kanału, natomiast do metody RegisterWellKnownServiceType przekazujemy oczywiście typ usługi, jej nazwę oraz określamy czy każde żądanie będzie obsługiwane przez nową instancję klasy implementującej usługę, czy można zadowolić się jedną.
Dziedziczenie SampleService z MarshalByRefObject jest niezwykle istotne, gdyż klient musi mieć możliwośc otrzymania referencji do obiektu usługi, kiedy będzie z niej korzystał.

Reszta nie wymaga komentarza, a w potrzebie zawsze znajdzie się przyjaciel w postaci F1

Klient jest równie prosty w implementacji:

namespace RemotingClient
{
    class Program
    {
        static void Main(string[] args)
        {
            string message;
            var service = (ISampleService) Activator.GetObject(typeof (ISampleService),
                String.Format("ipc://{0}/{1}", "RemotingHostChannel",
                    "SampleService"));
            Console.WriteLine("Write something and you'll get a surprise   (empty to exit)");
            while (!String.IsNullOrEmpty(message = Console.ReadLine()))
            {
                Console.WriteLine("{0}", service.ProcessMessage(message));
                Console.WriteLine("Your surprise: {0}", service.GetPayload());
            }
        }
    }
}

Chyba jedyną ciekawostką jest tutaj „adres” usługi, w którym rozpoznajemy znajome łańcuchy użyte w kodzie hosta. Wszystko śmiga, różne procesy komunikują się ze sobą i są szcześliwe, jak widać na załączonym obrazku:

Ponieważ, tak jak wspomniałem, .NET Remoting jest obsolete, zrealizujemy tą samą funkcjonalność z wykorzystaniem modnego i lubianego Windows Communication Foundation

WCF jest prosty jak ABC gdzie:

• A = Address, czyli adres pod którą dostępna jest usługa
• B = Binding, czyli sposób w jaki można się z tą usługą porozumieć (protokół, transport jak zwał tak zwał)
• C = Contract, czyli wspomniana wcześniej umowa o świadczenie usług

Kontrakt definiujemy niemal identycznie jak uprzdnio, dodając kilka WCFowych ozdobników:

namespace Contracts
{
    [ServiceContract]
    public interface ISampleService
    {
        [OperationContract]
        string ProcessMessage(string message);
        [OperationContract]
        Payload GetPayload();
    }
    [DataContract]
    public class Payload
    {
        [DataMember]
        public DateTime TimeStamp { get; set; }
        [DataMember]
        public int Value { get; set; }
        public Payload()
        {
            TimeStamp = DateTime.Now;
            Value = (new Random()).Next();
        }
        public override string ToString()
        {
            return String.Format("{0};{1}", TimeStamp, Value);
        }
    }
}

Odpowiednie atrybuty instruują WCF co jest czym i co jest dostępne dla klienta. Metody interfejsu które nie są opatrzone [OperationContract] oraz członkowie klasy bez [DataMember] nie będą widoczne po drugiej stronie barykady.
Istotna rzecz: jakby ktoś z jakiegoś niewyjaśnionego powodu chciał łączyć WCF z .NET Remoting – dobra nowina, .NET Remoting może korzystać z tej samej definicji kontraktu co WCF. Ozdobniki nie stanowią przeszkody.

Ponieważ chcemy komunikować się między procesami na tej samej maszynie, użyjemy efektywnego transportu named pipes.
I tak oto prezentuje się kod hosta:

namespace WCFHost
{
    class Program
    {
        static void Main(string[] args)
        {
            using (var host = new ServiceHost(typeof(SampleService),
                    new Uri("net.pipe://localhost")))
            {
                host.AddServiceEndpoint(typeof(ISampleService), new NetNamedPipeBinding(), "SampleService");
                host.Open();
                Console.WriteLine("Host is running, hit <RETURN> to stop...");
                Console.ReadLine();
                host.Close();
            }
        }
    }
    public class SampleService : ISampleService
    {
        #region ISampleService Members
        public string ProcessMessage(string message)
        {
            int processID = Process.GetCurrentProcess().Id;
            Console.WriteLine("{1}: Recieved message: {0}", message, processID);
            return String.Format("{1}: your input is \"{0}\"",
                                 message, processID);
        }
        public Payload GetPayload()
        {
            int processID = Process.GetCurrentProcess().Id;
            var result = new Payload();
            Console.WriteLine("{0}: generated payload {1}", processID, result);
            return result;
        }
        #endregion
    }
}

Kod sam się objaśnia, zgodnie z WCFowym ABC konigurowana jest usługa. Warto zwrócić uwagę, na to iż klasa SampleService nie dziedziczy juz po MarshalByRefObj.

Klient równie prosty:

namespace WCFClient
{
    class Program
    {
        static void Main(string[] args)
        {
            var factory = new ChannelFactory<ISampleService>(new NetNamedPipeBinding(),
                new EndpointAddress("net.pipe://localhost/SampleService")
                );
            var factory = new ChannelFactory<ISampleService>("SampleService");
            var service = factory.CreateChannel();
            string message;
            Console.WriteLine("Write something and you'll get a surprise   (empty to exit)");
            while (!String.IsNullOrEmpty(message = Console.ReadLine()))
            {
                Console.WriteLine("{0}", service.ProcessMessage(message));
                Console.WriteLine("Your surprise: {0}", service.GetPayload());
            }
        }
    }
}

I jak widać na kolejnym obrazku: znów działa

Proste jak ABC, czyż nie?
STOP!
Może być jeszcze prostsze a przy okazji bardziej elastyczne. WCF został tak zaprojektowany, aby każdą usługę i klienta można było dynamicznie konfigurować bez potrzeby rekompilacji kodu.
Zmieńmy zatem aplikację hosta dodając do niej plik konfiguracyjny:

<configuration>
  <system.serviceModel>
    <services>
      <service  name="WCFHost.SampleService">
        <endpoint address="net.pipe://localhost/SampleService"
                  binding="netNamedPipeBinding"
                   contract ="Contracts.ISampleService"/>
      </service>
    </services>
  </system.serviceModel>
</configuration>

Teraz host jest jeszcze prostszy i czytelniejszy:

namespace WCFHost
{
    class Program
    {
        static void Main(string[] args)
        {
            using (var host = new ServiceHost(typeof(SampleService)))
            {
                host.Open();
                Console.WriteLine("Host is running, hit <RETURN> to stop...");
                Console.ReadLine();
                host.Close();
            }
        }
    }
}

Klasa ServiceHost automatycznie na podstawie nazwy typu usługi (typeof) wspomnianej w atrubycie name elementu odszuka konfigurację i ustawi binding, kontrakt oraz adres.

Z klientem sytuacja jest analogiczna, konfiguracja:

<configuration>
  <system.serviceModel>
    <client>
      <endpoint address="net.pipe://localhost/SampleService"
                contract="Contracts.ISampleService"
                binding="netNamedPipeBinding"
                name="SampleService"/>
    </client>
  </system.serviceModel>
</configuration>

I oczyszczony kod:

namespace WCFClient
{
    class Program
    {
        static void Main(string[] args)
        {
            var factory = new ChannelFactory<ISampleService>("SampleService");
            var service = factory.CreateChannel();
            string message;
            Console.WriteLine("Write something and you'll get a surprise   (empty to exit)");
            while (!String.IsNullOrEmpty(message = Console.ReadLine()))
            {
                Console.WriteLine("{0}", service.ProcessMessage(message));
                Console.WriteLine("Your surprise: {0}", service.GetPayload());
            }
        }
    }
}

Prawda że ładniej?

Oczywiście to co opisałem jest wirzchołkiem góry lodowej jeżeli chodzi o WCF, ale mam głęboką nadzieję że może jakiejś zbłąkanej duszy pozwoli rozpocząć przygodę z WCF w bezbolesny sposób, bez konieczności przekopania się przez miliony stron opisów na początek.

Ponieważ zakochałem się z wzajemnością w Git, kod źródłowy przykładów możecie znależć na git://github.com/emdzej/blog_samples_ipc.git

Dzisiejszego pięknego i powtórnie zimowego dnia zaszła potrzeba stworzenia kontrolki, która miałaby dwa wzorce zawartości: nagłowek i ciało. Wszystko szło pięknie. Stworzyłem sobie kontenery do wzorców, odpowiednią kontrolke i wszystkie inne potrzebne rzeczy. Gdy jednak przyszło do wykorzystania okazało się, że kontrolki umieszczone wewnątrz wzorców nie mają odwołać w pliku designera, ani nie są dostępne „globalnie” na stronie. Jakby nie patrzeć całkiem normalne zachwoanie tego typu zwierza, do jakiego mogliśmy przyzyczaić się korzystając z DataGrid, Repeater i innych tego typu ustrojstw.

Wiedziałem, że jest możliwość, aby kontrolki wewnętrzne były widoczne „od ręki” i aby nie istniała konieczność używania FindControl w kontenerach… tylko jak? Totalne zaćmienie umysłu, nawet Google nie pomogło. Na szczęście przewinęło się słowo klucz TemplateInstanceAttribute. Jak już słowo klucz się znalazło, przypomniałem sobie o oczywistej oczywistości, czyli kontrolce UpdatePanel, która ma ContentTemplate, który zachowuje się dokładnie tak jak to sobie wymarzyłem.

Niniejsza wzmianka jest więc dla „potomności” – w przypadku jakby ktoś, kiedyś z niewyjaśnionych względów szukał rozwiązania a miał chwilowe zaćmienie

Do rzeczy. Zrobimy sobie kontrokę, która będzie pojedyńczym wystąpieniem elementu akordeonu – czyli czymś co ma nagłowek i zwijane ciałko. Całość będzie DIVem, nagłowek i ciało będzie także DIVami – stąd wykorzystanie Panel jako klasy bazowej zarówno dla kontrolki jak i kontenerów.

Kontenerki wyglądają tak:

namespace TemplatedControlSample
{
    public class HeaderTemplateContainer : Panel, INamingContainer
    {
        public string Title { get; set; }
    }
 public class BodyTemplateContainer : Panel, INamingContainer
    {
    }
}

A kontroleczka tak:

namespace TemplatedControlSample
{
    [ParseChildren(true)]
    [PersistChildren(true)]
    public class SimpleTemplatedControl : Panel
    {
        protected ITemplate _HeaderTemplate;
        protected ITemplate _BodyTempalte;
        public virtual string Title
        {
            get { return (string) ViewState["Title"]; }
            set { ViewState["Title"] = value; }
        }
        [TemplateInstance(TemplateInstance.Single)]
        [TemplateContainer(typeof(HeaderTemplateContainer))]
        [PersistenceMode(PersistenceMode.InnerProperty)]
        public virtual ITemplate HeaderTemplate
        {
            get { return _HeaderTemplate; }
            set { _HeaderTemplate = value; }
        }
        [TemplateInstance(TemplateInstance.Single)]
        [TemplateContainer(typeof(BodyTemplateContainer))]
        [PersistenceMode(PersistenceMode.InnerProperty)]
        public virtual ITemplate BodyTemplate
        {
            get { return _BodyTempalte; }
            set { _BodyTempalte = value; }
        }
        protected override void CreateChildControls()
        {
            ITemplate headerTempalte = _HeaderTemplate ?? new DefaultHeaderTemplate();
            ITemplate bodyTemplate = _BodyTempalte;
            HeaderTemplateContainer headerContainer = new HeaderTemplateContainer()
            {
                Title = Title,
                ID = "Header",
                BackColor = Color.Blue
            };
            headerTempalte.InstantiateIn(headerContainer);
            Controls.Add(headerContainer);
            headerContainer.DataBind();
            BodyTemplateContainer bodyContainer = new BodyTemplateContainer()
            {
                ID = "Body",
                BackColor = Color.Gray
            };
            if (bodyTemplate != null)
            {
                bodyTemplate.InstantiateIn(bodyContainer);
            }
            Controls.Add(bodyContainer);
            bodyContainer.DataBind();
            headerContainer.Attributes["onclick"] =
                String.Format("jQuery('#{0}').toggle();", bodyContainer.ClientID);
        }
    }
}

Cała magia tkwi w dodaniu atrybutu [TemplateInstance(TemplateInstance.Single)] do właściwości wzorców. Ot cała filozofia… eh

Pragnę zwrócić uwagę na dodanie atrybutu [ParseChildren(true)] do klasy kontrolki. Panel ma ten atrybut ustawiony w drugą stronę, jednak gdybyśmy tego nie nadpisali, wzorce nie byłyby przeparsowane przez ASP.NET i wszystko wylądowałoby jako zawartość Panel.

Jak możecie przekonać się sami ściągając kod z git://github.com/emdzej/blog_samples_templatedcontrol.git wszystko śmiga jak chciałem

Podziękowania dla Łukasza, który był źródłem „przewinięcia się” słowa klucza

W imieniu swoim i Łódzkiej Grupy Profesjonalistów IT & .NET oraz sponsorów mam zaszczyt zaprosić Was na konferencję DevDay, która odbędzie się 4. grudnia 2010 w Arterionie przy ul. Rewolucji 1905r. 82.

Przygotowaliśmy dla Was kilka interesujących sesji oraz konkurs, w którym można wygrać nowiutkiego Xbox’a z Kinectem

Zapraszam na stronę konferencji, gdzie możecie zapoznać się ze szczegółami oraz zarejestrować się na wydarzenie.

Dodatkowo zachęcam do odwiedzenia strony konferencji na Facebooku

Już w najbliższy czwartek 21 października 2010 odbędzie się kolejne spotkanie Łódzkiej Grupy Profesjonalistów IT & .NET. Tym razem czeka nas spotkanie wyjątkowe, gdyż ani jedna sesja nie będzie sesją techniczną.

Zaplanowaliśmy dla Was dwie sesje z gatunku miękkich. Obie jednak skierowane są dla środowiska IT. Dzięki uprzejmości Sandry Rogalskiej pracującej w firmie Modis Polska Sp. z.o.o. jako IT Recruiter, która poprowadzi dwie sesje („Rozmowa kwalifikacyjna” oraz „Profesjonalne CV programisty/informatyka„) dowiemy się m.in:

• Jak przygotować się do rozmowy kwalifikacyjnej.
• Jak poprowadzić profesjonalną autoprezentację.
• Co to jest mowa ciała i jakie ma znaczenie.
• Jak powinno wyglądać CV, co powinno zawierać, a czego nie warto w nim umieszczać.
• Jakie błędy najczęściej popełniane są przy tworzeniu CV i jak ich unikać.
• Jak tworzyć CV w odpowiedzi na konkretną ofertę.

Zapraszam wszystkich serdecznie w dniu 21 października 2010 o godzinie 18:00 do Centrum Komputerowego ZETO. Przypominam, iż wymagana jest wcześniejsza rejestracja na spotkanie.

Do zobaczenia!

Ostatnio trochę medialnego szumu powstało wokół Marszu Wyzwolenia Konopi jaki odbył się dziś w Warszawie. Pierwotnie pojawiła się w prasie (o ile dobrze pamiętam w Gazecie Wybiórczej) informacja, że władze Miasta Stołecznego Warszawy nie wydały zgody na organizację marszu, po czym marsz się odbył. Gdy usłyszałem o braku przyzwolenia do zorganizowania tego wydarzenia, pomyślałem – hipokryci (władze). No bo w czym taki marsz jest gorszy od Parady Równości dla przykładu? W wolnym kraju każdy ma prawo zamanifestować swoje poglądy (pomijając faszyzm, stalinizm i inne zabronione z uzasadnionych względów).

W ogóle dlaczego palących trawkę utożsamia się z ćpunami? W czym marihuana jest gorsza od alkoholu czy papierosów? Najprostsza odpowiedź jaka przychodzi mi do głowy – nie przynosi korzyści państwu. Wszak za papieroski i wódeczkę płacimy nie mało, z czego ogrom kwoty to akcyza, która trafia wprost do Skarbu Państwa. No a jak pieniążki płyną sobie wartkim strumieniem, to przecież nie może być to nic złego. Prawda? O ile więcej zła wyrządza alkohol, czy papierosy? A mimo tego są legalne? Ktoś powie: ale narkotyki uzależniają. Wszystko uzależnia, picie, palenie, seks, spacery, bieganie, adrenalina, wszystko. Uzależnić można się od wszystkiego, bo to jest kwestia ludzkiej psychiki. Można się uzależnić od jedzenia i czekolady; otyłość – jakie żniwo zbiera ta choroba co roku? Zawały, cukrzyca, niepełnosprawność… I co? Jakoś wolno jeść. Wolno pić i palić.

Sam nie palę ani papierosów, ani trawki. Znam jednak multum osób, które paliły lub palą nadal – każdy z nas zapewne zna. Nikt, dosłownie nikt jakoś się nie uzależnił. Nie uzależnił się w większym stopniu niż można się uzależnić od dobrej zabawy, dobrego drinka, kawałka czekolady czy dawki adrenaliny podczas sportowej rywalizacji.

Nie słychać, aby w krajach gdzie marihuana jest legalna, wszyscy obywatele leżeli w szpitalu na odwyku.

Uważam, że w czystej nie doprawionej chemiczne trawce nie ma nic złego. Nie dewastuje organizmu tak jak chemia, jak chociażby LEGALNE dopalacze.

Jeżeli już o dopalaczach mowa, to podstawowym błędem jaki został popełniony przez polskich ustawodawców jest istnienie czarnej listy substancji niedozwolonych. Ponieważ pomysłowość ludzka nie zna granic, co rusz na rynku będą pojawiać się kolejne chemikalia o działaniu psychoaktywnym. Czarna lista za tymi zmianami nie ma prawa nadążyć. Częściowym rozwiązaniem tego problemu jest zastąpienie czarnego białym, czyli wprowadzenie białej listy – listy substancji dozwolonych. Znacznie efektywniejsze i elastyczniejsze.

Ja osobiście jestem za wolnością jednostki, wolnością której granice stanowi wolność innych. Jeżeli ktoś ma ochotę truć się chemicznym świństwem – proszę bardzo. Jeżeli jest na tyle głupi, aby doprowadzić do samozagłady – nie widzę problemu. Dla podatników to też ulga. Jest jeden warunek – ktoś kto wybrał taką właśnie ścieżkę nie powinien być leczony z moich pieniędzy. Brakuje Ci rozsądku? Masz problem. Kropka. Owszem świat nie jest czarno-biały i każdy może zbłądzić, ale od tego ma się głowę na karku i innych ludzi wokół, aby się odnaleźć. Robienie z tego sprawy państwowej jest chyba skazane na niepowodzenie.

Może więc warto wprowadzić akcyzę i zalegalizować handel marihuaną. Przynajmniej będzie wiadomo, że pochodzi ze sprawdzonego źródła i nikt jej nie „ochrzcił” jakimś kwasem. A jeżeli ktoś nie umie poradzić sobie z samym sobą to równie dobrze może zniszczyć się alkoholem, który może kupić na każdym kroku…

Tym razem chciałbym zwrócić Waszą uwagę na serię artykułów autorstwa Jammes’a Michael’a, w których opisuje kilka cech języka C#, które sprawią, że będziecie kodować czytelniej i efektywniej. Zachęcam wszystkich do lektury.

Cykl składa się z trzech części:

• C#/.NET Five Little Wonders That Make Code Better (1 of 3)
• C#/.NET Five Little Wonders That Make Code Better (2 of 3)
• C#/.NET Five Little Wonders That Make Code Better (3 of 3)