XAML Binding: Path és ElementName

Ha WPF XAML-ben valami másik objektum tulajdonságához szeretnénk bindolni, akkor ezt könnyedén megtehetjük a ElementName paraméter beállításával.
FONTOS, hogy ebben az esetben a hivatkozott property útvonalát is módosítani kell, elé kell tenni, hogy DataContext. Ekkor fogja megtalálni a célobjektum általunk keresett property-jét.

Azaz például:
{Binding Path=DataContext.DesiredProperty, ElementName=target}

Amennyiben megfeledkezünk arról, hogy az ElementName használatával a célobjektum DataContext property-jében kell keresnünk a saját modellünket, akkor komoly problémát fog okozni az, hogy semmilyen hibát nem kapunk majd, csak nem fog működni. Lefordul és fut hiba nélkül, pusztán nem működik.

Hülye hiba, WCF & net.tcp & "nagy" wsdl

Érdemes elolvasni, nagyon cumi.
Tegnap beleszaladtunk egy olyan hibába, hogy egyik pillanatról a másikra az svcutil nem tudta legenerálni a kliens proxy-t a wcf service-ünkhöz.
Ami változott, néhány függvényt hozzáadtunk az interface-en. A hibaüznenet annyi volt, hogy a szerver bezárta a kapcsolatot, nem lehet csatlakozni. Próbáltam "felezéssel" kitalálni, melyik metódus a hibás, kikommenteltem felét, svcutil-al generáltam, figyeltem elszáll-e.
A végére maradt 4 metódus, látszólag semmi extra nincs bennük. Mivel ugyanolyan bemenő és kimenő paraméterekkel van már benne "jó" metódus más névvel, kezdett gyanús lenni. Levettem a kommentet, és másik 4-et kikommenteltem, random, tök mindegy mit.
Ugyanúgy ment, tehát NEM a metódusokkal volt baj, hanem azok számával. Nem volt sok, 30-35 metódus, ez meglehetősen kevés ahhoz képest, ami egy service-en általában szokott lenni, de rákeresve a "wcf limit method net.tcp svcutil" kulcsszavakra a következő oldalon egy nagyon szép nyomozás után találtam egy meglehetősen fura leírást és megoldást:
http://social.msdn.microsoft.com/forums/en-US/wcf/thread/d7e36a08-5835-42f8-8eec-8e005cb063c9/

A lényeg, hogy az svcutil-nak is van egy svcutil.exe.config állománya, amiben a net.tcp binding beállításai a default-ok, tehát a már szopások során megismert maxTableCharCount, maxBufferSize, maxReceivedMessageSize stb. paraméterek nincsenek beállítva.

Egy megoldás a problémára:
Kimásoljuk az svcutil-t a konfigjával együtt a proxy generáló parancsunk mellé (vagy bárhova), és abban a konfigban a fenti linken leírt módon ezeket a beállításokat megcsináljuk. És voállá, megy a proxy generálás...

A Microsoftnál egy kicsit jobban átgondolhatták volna ezt... vagy legalább egy normális hibaüzenetet dobhattak volna.

FallbackValue binding-nál WPF-ben

System.Windows.Data Error: 11 : Fallback value 'false' (type 'String') cannot be converted for use in 'Visibility' (type 'Visibility'). BindingExpression:Path=IsNewsItemFolderMode; DataItem=null; target element is 'ToolbarButton' (Name=''); target property is 'Visibility' (type 'Visibility') FormatException:'System.FormatException: false is not a valid value for Visibility. ---> System.ArgumentException: Requested value 'false' was not found.

Ahogy a FallbackValue definíciójából kiderül (Gets or sets the value to use when the binding is unable to return a value, http://msdn.microsoft.com/en-us/library/system.windows.data.bindingbase.fallbackvalue.aspx) ez az az érték, amit akkor használ az alkalmazás, ha nem sikerül a binding (hogy mi az, ami sikeresnek számít, ld. az előző linken). Szóval az itt megadott false-t nem a konverter kapja meg, ahogy a kód írója talán feltételezte, hanem közvetlenül a binding célja. Így false helyett pl. Visible, Collapsed vagy Hidden szerepelhetne itt.