OMFG AppleTV, seriously? Wipe yourself clean, why don't you?
Ok, here's a feature of AppleTV that can only have it's origin in some devils bargain with Content industry: Once you associate an iTunes instance with AppleTV for sync, you better not ever want to change it, because in the blink of an eye, you will staring a freshly wiped HD.
See, syncing means that whatever is on your PC/Mac is also on your AppleTV. So if you remove it from the PC, it disappears from your AppleTV. Ok, fine, a bit stupid a way to do content management on the AppleTV, but maybe i'll buy that it simplifies things, since all you have to do it keep things organized in AppleTV and all is good.
But here' the kicker, you ever change your AppleTV association to another iTunes, all is wiped of the AppleTV after one quick dialog. And no, oh, it's only hidden in case you re-associate because you realize that was not what you meant to do. No, you now get to re-synch 150GB back to your AppleTV. All for a second of misreading a dialog and clicking the wrong button. Wow! Really? That's great UI simplification. User makes mistake, gets to sit around for a couple of hours while AppleTV re-synch.
Any you cannot tell me that the brilliant minds at Apple came up with this scheme because it was just the most intuitive UI they could think of. No, this is all about the content industry being deathly afraid that someone might take their AppleTV to a friends house, copy all his content and then take it back home. As if this assinine sync behavior prevents something like that.
Grrr.. This is just stupid. 8 out of 450 items synced.
Labels: apple, appleTV, braindead
The riddle of the disappearing WPF databinding
I'm currently on a custom control that has a bunch of panels slaved to each other via databinding. And I ran into a bug where moving an element around would suddenly break the sync with the other panels. Nothing in the Output about data-binding failing, so i inspected it with
Snoop to see that my data-binding had just up and gone away. So I tracked down the suspect code and monitored the data source with
Mole as i stepped through and saw that the data-binding went away right after I set the dependency property.
Yeah, not really magic at all. A quick look at the Xaml showed that I had left this particular binding as default (i.e. OneWay). And if you have a OneWay binding and manually set the dependency property, the binding gets overwritten and goes away. Switching the binding to Mode=TwoWay restored my sync.
Labels: c#, wpf
WPF Custom Panel layout and Dependency Properties
Just a quick note I learned the hard way when creating custom panels in WPF:
If your panel has dependency properties or attached properties on its children that affect measure and/or arrange, calling InvalidateMeasure or InvalidateArrange won't necessarily do the trick. For that matter, calling these methods isn't even necessary. Instead use the
FrameworkPropertyMetadata Metadata class to set appropriate
FrameworkPropertyMetadataOptions.
So if you have a Dependency Property on your panel that affects the measure or arrange of its children, make sure it has FrameworkPropertyMetadataOptions.AffectsMeasure and/or FrameworkPropertyMetadataOptions.AffectsArrange set.
Similarily, if your panel has an attached property for its children, whose modification affects how that child is laid out, set FrameworkPropertyMetadataOptions.AffectsParentMeasure and/or FrameworkPropertyMetadataOptions.AffectsParentArrange.
Now layout and arrange are properly invalidated and called for you.
Labels: c#, wpf
