TENCOKACISTROMY: cekal bych neco jako kdyz z listu odebiras polozku, ktera tam neni O.o

Prave jsem asi objevil ameriku zjistenim, ze vicenasobne odebrani event handleru by defaultne nehaze vyjimku, jak jsem si myslel :)

border.ManipulationDelta += BorderManipulationDelta;
border.ManipulationDelta -= BorderManipulationDelta;
border.ManipulationDelta -= BorderManipulationDelta; // nic se tu nestane

Teda vyjimku to hazet muze v zavislosti na implementaci toho eventu:

public event EventHandler MyEvent;
{
add { _delegate += value; }
remove { _delegate -= value; } // tady muze byt test a hazeni vyjimky
}

Mam ve WPF ListView, ktery je nabindovany na IBindingList a chci tam pres drag & drop presouvat polozky (je to playlist). Bohuzel cilem je aby to bylo spis drag & move, nez drag & drop. Je nejakej pripravenej zpusob, jak to udelat, a kterej vypada pekne a je spolehlivej? Ted mi to funguje, ale to preskakovani polozek vypada divne. Uplne nejlepsi by bylo, kdyz by se ty vymeneny polozky animovali jak se prohazujou.

NECROMAN: To jsi schopen. A jsi schopen krokovat i do toho aspektu.

Jen jsem říkal, že nevím, jak by se debugger choval, kdyby se ten get či set prostě nezavolal. Kdyby sis v aspektu třeba napsal, že za takové a takové podmínky nevracej hodnotu, ale třeba default. Pak nevím, jestli by ti to zastavilo nebo ne.

SLUPKA: jde mi o to, ze obcas potrebuji debugovat kolikrat se treba vola getter nejake property a zda uz je ta properta v dany okamzik spravne nasatvena nebo ne...

NECROMAN: ten jejich atribut je jejich použití aspektů - nejsem si jist, jestli to platí pokaždé (jde napsat aspekt, který způsobí, že se vůbec volat get či set nebude a pak nevím, jestli to ten breakpoint hitne). Ale tady ten get, set nijak upravený není, krom toho, že po tom setu se notifikují změny.

SLUPKA: takze kdyz pouziji ten atribut [NotifyPropertyChanged] na tridu, kde mam treba
public string Title { get; set; }
tak je mozne dat breakpoint na getter a setter te property po tom, co mi to PostSharp upravi?

P19: https://github.com/speier/mvcassetshelper

Nemate predstavu, jak by se dalo v extensio metode u mvc automaticky nareferencovat javascript knihovna do hlavicky? Nebo nejak pristoupit do section?
Dik

NECROMAN: INotifyPropertyChanged obchazime pres CallerMemberNameAttribute. Ale jinak to pouzivame pro lazyloading a lazysaving objektu do objektovy databaze. Zrovna PostSharp je dobrej v tom, ze upravi i *.pdb soubory, takze neni problem s debugovanim.

BUTHRAKAUR: pouzivam MVVM Light s upravenymy zdrojaky, no nevadi...

Jinak jaky mate nazor na frameworky, ktere pri kompilaci injectuji skript do vaseho kodu, typicky PostSharp pro zjednoduseni implementace INOtifyPropertyChanged a podobne? Sice to na obrazcich vypada hezky, ale ke mne do aplikace to nesmi, jakmile chce clovek debugovat kod, ktery je vygenerovany behem compile time, tak ma smulu.
Design Pattern Automation – PostSharp
http://www.postsharp.net/

NECROMAN: z hlavy ted nevim, pze jsem delsi dobu WPF/SL nedelal, ale Caliburn/Micro to ma vyreseny - zkousel jsi se na nej kouknout?

TENCOKACISTROMY: asi tak, v SharePoint bylo bezne volani reflexi treba internal metody pro zakladani SPListu, protoze verejne API neumoznovalo vse potrebne. Pak byl treba problem, ze SP3 pro SP2007 zmenil signaturu tohoto internal interface a aplikace prestala fungovat, jo, take jsem od toho rad utekl :)

VIRTUALVOID: Tak ja nepredpokladam, ze bych neco takovyho pouzival v produkcnim kodu. To by musel bejt fakt hodne extremni pripad. Hacky jsem do produkce musel nasazovat zatim jen u Sharepointu a od nej jsem utekl.

Vite o nejake best practice, jak pouzivat Dependency Injection v code-behind ve WPF/Silverlight pages? stranky nelze vytvaret pokud vim na vyzadani, ale vzdy musi obsahovat:

public XYPage()
{
InitializeComponent();
}

Zatim to resim tak, ze si tam pres service locator v konstruktoru stranky vyzadam potrebny viewModel, ale co jsem cetl, tak explicitni volani ServiceLocatoru neni dobry zpusob.

InitializeComponent();
model = ServiceLocator.Current.GetInstance<MainViewModel>();

Druha moznost me napada primo databinding DataContextu v XAMLu a v konstruktoru jen ulozeni teto instance.

DataContext="{Binding Main, Source={StaticResource Locator}}"

InitializeComponent();
model = (MainViewModel)DataContext;

TENCOKACISTROMY: ktory sa pri najblizsom update compilera zmeni...

NECROMAN: Tak tohle je super uber prasarna. Ale je to fakt peknej trik.

NECROMAN: to je docela zajímavé a zajímalo by mne, jak moc jistě to funguje. Protože v době, kdy byl .NET 4.0 nový (neboli nevím, jestli se to ještě stále tak chová), tak pokud jsem udělal třídu s klasickým destruktorem (takový ten co obsahuje this.Finalize(false)) a při vytváření argumentů pro konstruktor padla výjimka, tak v debug režimu se nestalo nic (nebo jsem si ničeho nevšiml), ale v release režimu se zavolal destruktor a tam padla výjimka, protože this bylo null. Zajímavé bylo, že se mi nepodařila nijak odchytnout (ani na AppDomain unhandled exceptions), takže zjistit v čem byla chyba byla opravdu chuťovka. A jelikož jsem nikde GC.Collect nevolal, tak ta výjimka padala opravdu krásně náhodně.