Interesting approach Scott, thanks for sharing! Did some Blend hacking back in 2008 to do the Colorful addin ( http://colorful.codeplex.com/), and at the time extensibility was fairly limited. It looks like this is at least a bit better (hopefully we'll have some documentation when Blend 4.0 RTM?).
I couldn't figure out how to programatically add custom XAML to the open document/App.xaml or any resource dictionary. So they way I managed to integrate the add-in was through drag-and-drop and spying on the clipboard. So in general I produce XAML on the clip board Blend can understand. Having an API giving you DOM like access would be awesome. - Jonas On Fri, Apr 2, 2010 at 11:03 AM, Scott Barnes <[email protected]>wrote: > *Adding two Microsoft Rockstars whom may find the below of interest - or > not .. ;) hehe* > > > > *Pete:** what's your thoughts on David's approach below in the url? > dangerous or safe? * > > * > http://davidburela.wordpress.com/2010/02/02/guide-to-creating-expression-blend-3-addins/ > * > > > > *David / All,* > > heh funny how we're both attacking blend from different angles and kind of > arrive at the same entry point - yet - didn't talk to one another once about > it.. Go Readify! J > > > > I think your approach is much cleaner than walking the VisualTree like mine > and I'm pretty sure yours is the "supported" way of doing things (i.e. > Blend's not likely to introduce breaking changes to its current structure - > so I've been told). > > > > > > I'd love to see Blend take on even more of an extensibility than it has > today, in that for example: > > [CategoryVisibility("Font",false)] > > [CategoryVisibility("Common Properties",false)] > > [CategoryPanel(typeof(MyPanel),"Panel Name","Description")] > > public class ConsoleWindow : ContentControl > > { > > > > This would effectively inject your own Panel into the Property Grid. As I > think if we had a basic SDK/API to tap into and route actions through, we > could keep a tighter control over how UserControl's Turnkeys work etc. Then > using API's like: > > > > > > MyCustomControlTag tag = new MyCustomControlTag(); > > tag.SetType(typeof(MyCustomControl)); > > tag.Name = "Item01"; > > tag.MyCustomProperty = new MyValue(); > > BlendVisualDOMHelper.CreateElement(myParentTag, tag, > newTagOrderAttribute(TagOrder.Later), TreeBrowseable.No); > > > > This would also allow as to write XAML through a controlled set of > approaches (Much like HTML DOM access today). > > > > · We new-up a MyCustomControlTag which inherits a BaseTag class > (usual UserControl / Control properties etc attached). > > · We define the "Type" so that it can auto-resolve the xmlns="" for > us before injecting it into your XAML at design-time. > > · We can access our "Custom" properties as they derive from > MyCustomControl > > · We then Inject this into the XAML DOM via BlendVisualDOMHelper > through a factory method - CreateElement. > > · We then feed in the tag and make sure its attached to its > ParentNode. > > · We then feed in an Ordering attribute (I quite like how > PropertyOrder works today in Design-time projects for given properties) > > · We then define whether or not this node is "Visible" on the > Objects & Timeline hierarchy as at times we want to make knucklehead tags > visible while at the same time for tags with basic functionality we often > may opt out - having the choice would be great. > > > > Combine these two concepts together and I'd be pretty happy with the way in > which I could mutate Expression Blend and do functional things to enable me > to keep a tighter reign over framework usage for both developers and > designers - essentially force-fit them into following a set path vs. giving > them 101 properties they can tweak as well it at times is unnecessary and > often causes more pain than its worth. > > > > eg: I managed to customize Blend for my "ConsoleWindow" control i'm > writing: > > > > > > > > That's all she wrote - in that you can't access anything else via Blend. > You'd have to actually go in via Code to do it and i figure if you try doing > things via that route well all bets are off anyway. > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *David Burela > *Sent:* Friday, April 02, 2010 6:47 PM > > *To:* ozSilverlight > *Subject:* RE: How to hack Expression Blend. > > > > Along a similar path, here are my notes on how to create your own addins > for expression blend > > > http://davidburela.wordpress.com/2010/02/02/guide-to-creating-expression-blend-3-addins/ > > > > -David Burela > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Tim Heuer > *Sent:* Friday, 2 April 2010 4:36 AM > *To:* ozSilverlight > *Subject:* RE: How to hack Expression Blend. > > > > Awesome. > > > > *Tim Heuer* *|* +1 (602) 405-4567 | *Microsoft Silverlight* > > *blog*: http://timheuer.com/blog/ | *twitter: > *...@timheuer<http://twitter.com/timheuer> > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Scott Barnes > *Sent:* Thursday, April 01, 2010 6:58 AM > *To:* ozSilverlight > *Subject:* FYI: How to hack Expression Blend. > > > > In case any of you are curious, here's some basic "how to" on hacking > Expression Blend's UI, tonight I wrote a quick blog post documenting it (ie > you can really goof around with the UI inside the tool) > > > > How to hack Expression Blend - http://bit.ly/9e4GQd > > > > Would love to know if any of you are tinkering around in this space as > well? any insights/tips? > > _______________________________________________ > ozsilverlight mailing list > [email protected] > http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight > >
<<image001.jpg>>
_______________________________________________ ozsilverlight mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight
