Články v kategorii Silverlight
Ve WPF lze vytvořit attached události - Attached Events, někdy také nazývané Custom routed events. Ty nám obdobně jako Attached Dependency Properties, umožňují k libovolnému UIElementu přidat vlastní v tomto případě událost, kterou můžeme na elementu vyvolávat a odchytávat. Ve WPF se toto provádí pomoci třídy EventManager, kterou lze jako attached události registrovat přímo RoutedEvent.
V Silverlightu bohužel attached události nejsou implementované, viz msdn:
“Silverlight does not support creating a custom routed event. The only routed events available in Silverlight are the ones that are defined by existing Silverlight classes, as listed in the "Routed Events" section of Events Overview for Silverlight.” (viz. také Routed Events in Silverlight)
Při nastavování focusu se Silverlight ListBox kontrol defaultně chová tak, že je focus nastaven na první (případně poslední pří Shift+Tab) prvek. Tento “divný” stav je zobrazen na obrázku. Já bych toto chování označil spíše přímo jako bug než vlastnost, očekávané chování je samozřejmě nastavit focus na označený prvek v ListBoxu (tak jako ve WPF). Horší chování pak ještě nastává v případě, že ListBox je naplněn více prvky a je v něm tedy vertikální posuvník.
Pokud se v Silverlight koukneme na kontrol TextBox, zjistíme, že již obsahuje vlastnost Watermark, ta je však bohužel implementována takto:
throw new NotImplementedException();
Pojďme to udělat lépe.
Před nedávnem jsem v jedné Silverlight aplikaci potřeboval provést přechod z dané aplikace na určenou adresu (ekvivalent redirectu), ale metodou POST s odesláním formulářových dat. V tomto článku uvádím řešení tohoto problému.
V článku zde jsme si ukázali jak nezávisle na konkrétní infrastruktuře nebo typu aplikace sestavovat URL, když známe base URL a k této base relativní URL. Dnes si naopak ukážeme jak sestavovat URL konkrétně v Silverlight aplikaci v případě, že známe app-relativní URL tj. pokud chceme v Silverlightu sestrojit URL zdroje umístěného na webu, který danou aplikaci hostuje.
V tomto článku jsme si ukázali jak je možné v Silverlight aplikaci ošetřovat výjimky, které vzniknout při zpracování operace WCF služby na serveru. To nám umožní buď zachytit specifickou výjimku, pro kterou ve službě definujeme fault kontrakt nebo pouze přenést na klienta debug informace v případě obecné (neošetřené) výjimky. V obou těchto případech neobsahuje ale výjimka, která je na klientu vyhozená, původní stack trace prováděného asynchronního volání. Nyní ukážu způsob jakým lze i toto řešit.
Silverlight 5.0 pomoci Async Targeting Pack podporuje použití nové syntaxe resp. nových klíčových slov async/await. Pokud ale do Silverlight projektu přidáme referenci na WCF službu není zde podporováno automatické “zaobalení“ asynchronních volání operací WCF služby do metod vracející objekt Task. Toto si musíme udělat sami.
Pokud používáme v Silverlight aplikaci kontrol AutoCompleteBox plněný větším množství prvků (např. nad 1000), setkáme se s výkonnostním problémem, kdy první zobrazení dropdown seznamu je velice pomalé. Toto můžeme spravit jednoduchou úpravou ControlTemplate tohoto kontrolu.
V každé Silverlight aplikaci musíme zpravidla nějakým způsobem řešit ošetřování chyb vznikajících na serverové straně při volání operací WCF služby. V tomto článku se nebudu rozepisovat o tom jak ošetřování chyb ve WCF funguje a jaké jsou obecně možnosti a způsoby řešení, jen dodávám, že se celkově nejedná o triviální problém (v Silverlightu jsme navíc omezeni například tím, že výjimky nelze serializovat apod.) Místo toho zde předložím jeden způsob, který v poslední době docela úspěšně používám.