Ryan Dawson on Longhorn

The software we think, but do not write

  • Transitions are King

    Most everyone probably notices a disconnect in the practices that I suggest in comparison with other members of the community--which more or less boils down the scenarios we are attempting.

     

    So, although I can’t tell you what everyone else is working on, I will try to explain the types of things I am doing so you can understand why it seems that I need to break all of the rules.

     

    First of all, transitions are king. Here are some different examples:

    • Fading an element in by changing the Opacity from 0 to 1
    • Translating a element from an off-screen location to center stage
    • Cross-fading colors
    • Scaling an item from one size to another
    • Wiping an OpacityMask across an element
    • Using a 3D composition (spinning, etc)
    • Etc

     

    The list goes on, and it’s pretty much limitless. Anyway, I think the next generation UX relies on animations. These subtle, yet slick transitions are what make a meaningful experience. So, the value isn’t in stark animations, it’s in something that is transparent to the experience in the long run—but in the short run--make it fun to use. The thing is that development time never gets shorter--instead we use it for other things. So, in this case, we use it on the interaction design--which by the way is something that isn’t too easy for designers to envision, so it really allows a creative outlet for the developers. Switching out these transitions and trying different stuff is where the fun is at. It’s really just creative time, because the developer gets to experiment with all the different transitions and find the best one.

     

    Anyway, back to the point. I can’t stress enough how important transitions and animations are to the experience (But I also can’t tell you what good design is. The closest I can get is a rough guideline, but in the end, it’s just chaos). The thing is that most of the time it takes a stranger and more robust solution to fulfill these needs. It requires more logic, which requires more handling on the actual elements. So, this is why I questioned the viability of DataTemplates. In practice, the data is probably coming in asynchronously, but the UI is loading immediately, so you have visual queues representing the current state of the element, while also having a nice UI.

     

    John Gossman talks about switching out DataTemplates when you want to represent different states in a UI, and this works fine for some things, but the reason it doesn’t work for me is because you can’t have transition animations when you rip out one template for another. And, if you remember, I believe that transitions are essential to the experience. You can go 2 ways with your application--you can design it for the users, or you can design it for the coders. The user experience isn’t an afterthought. It’s not something that you add in later--it’s something you mold the code around (Leave the back-end part of your application to robust software architecture, but code your front-end around the idea of ripping it out at any time).

    PostTypeIcon
    976 Views
  • DataTemplate Viability

    What’s the long term viability of DateTemplates?

     

    In theory, it’s an excellent idea. In practice, though, I don’t think it pans out.

     

    For the unknowing:     A DataTemplate is an automatic visual that replaces a data type within an ItemsControl (ex. ListBox). So, I could add a data structure named Person to a ListBox, and it would automatically replace it with a DataTemplate that I have defined. The nice thing is that you only have to work with data structures.

     

    So, the problem is simply this—data is dynamic, dynamic data needs more logic to run. DataTemplates have no notion of logic.

     

    You see, in trying to separate the data from the presentation in such a way just doesn’t work. You need to be able to talk to the visual at any time, and with DataTemplates, that just isn’t possible. And, believe me, I’ve tried various things (tying to add properties within the actual data structure, so the DataTemplate can respond—besides this being a no-no in terms of data management, it just doesn’t really work).

     

    So, the ContentControl is where you need to be. But, don’t use the automatic DataTemplate swap-out (which means don’t define a DataTemplate for the data type of the content you are placing in the Content property). Also, subclass ContentControl—because this is where you get to place interesting logic that can manipulate the data and fire events for the ControlTemplate to recognize. In general, this class is the façade between the Visual and the data. Using an automatic solution like a DataTemplate just doesn’t work.

     

    Now, in cases where the data isn’t dynamic, by all means, use the DataTemplate—it’s too easy to pass up. But, obviously everyone probably understands that most data within an application is dynamic, so…

    PostTypeIcon
    1,823 Views
  • Hand-written XAML

    Although I was an initial critic of the mini-languages in XAML, the productivity gains are far too great to keep that opinion. The debate is pretty interesting, though, and it boils down to two sides: tools, or hand-written.

     

    I think the mini-languages are mostly going away because Sparkle couldn’t handle it. Obviously, it’s harder to guarantee consistency in a XAML file when you have both hand-written and tool-generated code going in. It’s also easier for the XAML parser. All around, the tools favor one representation of an element, and that’s just life—it’s easier.

     

    That’s not the real question, though. The real question is whether the tools are going to be good enough to use. If so, getting rid of the mini-languages is a non-issue. On the other hand, if they aren’t, well, we have really shot ourselves in the foot.

     

    More so, some people will always use the tools—they just don’t know how to write code. So, the question gets bigger when you decide which segment of the market should be favored. The guys who don’t know the code at all, and use tools—or, the guys who spend all day hand-writing XAML…

     

     

    Of course, there is one tool that you could change and this would definitely be a non-issue. Just add code snippets into Visual Studio for these things…Or, better syntax completion…

     

    Don’t get me wrong, I don’t really have an opinion, I just write XAML that is accepted by the parser, and that is usually good enough for me.

    PostTypeIcon
    979 Views
  • EnsureVisuals

    Clarification:

    Logical Tree – the hierarchy of controls that compose your overall UI.
    Visual Tree – the hierarchy of elements that compose a single Control.

    In the case that you are wiring up dynamic controls, and then quickly after, firing events that access elements within the VisualTree, there is something you need to know…

    If the debugger throws an error that it can’t find a certain element within your VisualTree (which is the hierarchy within a ControlTemplate), it means the VisualTree has yet to be composed. The quick and dirty way to fix this to call EnsureVisuals() on the Control before firing the event.

    Most people won’t hit this, but I’ve started to notice this somewhere around the 5215 timeframe. Prior to this time, there was obviously a different loading strategy and you wouldn’t run into these problems.

    PostTypeIcon
    908 Views
  • Frames

    How do I get a web browser within Avalon?

    Until yesterday, I had been creating a WindowsFormsHost that held a WebBrowser (WinForms interop).

    But, there is a better way…

    <Frame Source=”http://www.frogdesign.com” />

    A Frame is a generic Avalon Control that can be placed anywhere. And, in case you’re wondering, there is going to be another story around HTML for Avalon that has yet to hit the street.

    PostTypeIcon
    1,221 Views
  • XAML & C# cont'd

    More clarification:

    XAML is a language (technically this is false, since it is compiled into C# first and then into IL, but you get my drift). So, if XAML is a language and C# is a language it's perfectly legal to compare the two.

    At the root, the comparison is about speed of development. XAML has no preference towards UI—it just happens to be good at it.

    So, in the end, don’t think of XAML in terms of the presentation. That’s where everyone gets mixed up. I let people call Avalon=XAML, but that is only for consistency. They are different. They have no relation. But, there is a strong correlation between Avalon programming and XAML being the language of choice for the presentation aspect.

    So, the initial point I was trying to make is that you do have a choice between using XAML and C#. Each has its strong points, which I laid out in my previous post…

    The more dynamic the UI, the harder it is to use XAML. XAML is a pre-compiled thing (at least if you care about performance). So, if you need to programmatically add the elements, you’re probably looking at C#. If it’s static, you’re probably looking at XAML. These aren’t hard rules, just merely the probabilities.

    PostTypeIcon
    1,615 Views
  • XAML & C#

    Filed under:

    Where do you draw the line between XAML and C#?

    When to use what and where?

    The short of the stick is that many people associate XAML as the same thing as Avalon. In their book, it is the same (XAML is a catchier word than most other substitutes). As can be proven, XAML is actually a general purpose language for describing “things” in XML, but who cares about that. For now, it is related to Avalon.

    So, the deal is that XAML is XML and XML is goodness. No, the truth is that both XAML and C# bring different things to the table—both must be equally accessible in the tool belt.

    XAML is good at describing a hierarchy of “things,” which is perfect since we use the same concept of hierarchy to build a UI. We nest Buttons within Panels which are nested within Windows. Perfect. So, the beauty is that you get automatic insight into your hierarchy, which can greatly speed the time to produce a solution. More so, it is easy to navigate to particular section on your dialog and rip it out to replace with something different.

    Secondly, XAML in many cases is definitely the shorthand version of the same thing you could write in C#. So, the question is why wouldn’t you use it? Defining a Fill is as easy as writing Fill=“Red,” while in C#, that can be rectangle.Fill = new SolidColorBrushes(Colors.Red);.

    Thirdly, and less obvious, it is highly invaluable to save the naming of “things” (within your XAML) for the most important “things” you want to reference in C#. You see, if you only have to name one thing—like the Ok Button, for instance, you can make a very understandable name. On the other hand, in C# code, you have to name each “thing,” so creating the Ok Button could lead to these objects with various names: OkPanel, OkTextLabel, OkButton, OkButtonAnimation, etc…The list goes on…

    Now, since I have just finished bashing C#, why in the hell would I use it. Well, I spoke so highly of XAML, but the truth is that I probably use XAML for 15-20% of my total code. Why? Well, programs are full of logic—that is the value-add. And, the truth is that C# is far superior, considering XAML doesn’t even have a notion of logic. So, although you can get 20% of the way with XAML, don’t forgot that people want interesting applications, and those only come with a strong C# background (A Computer Science background wouldn’t hurt either—for the logic part). Oh, and by the way, most of what I build are demos and prototypes. So, the 15-20% goes way down as you start building real applications—way down…

    The trick is obviously finding the right balance. Defining your Control hierarchy in XAML is a definite must. Also, it is highly productive to write all of your Storyboards and Triggers in XAML. They tend to grow rather quickly in size…

    So, here’s how I break things up. I create a class in C# that subclasses ContentControl. Then, I create a XAML file with the same name that has a top-level element as ContentControl. Within the body of the XAML for ContentControl, I define my hierarchy in any way I see fit (naming any controls that need to be referenced in C#). And, within the Resources section of the ContentControl (still in XAML), I create any DataTemplates or Styles that I need. Obviously, all of the logic is within the C# that handles the hierarchy in the XAML. The trick for any XAML to be wired up to the C# comes in one quick method that you call from the constructor of your class ->InitializeComponent();. Remember, that’s where the tire hits the road…

    Going even farther, I usually want custom events and DP (DependencyProperties) for my Controls within the hierarchy—like my items within the ListBox, so I create a Style for that. You may ask why I want custom events and DPs. The reason is that it is far easier to respond to Triggers and EventTriggers within a ControlTemplate than anywhere else. So, to get the custom events, I have to subclass the Control and add them (ListBoxItem for example). Then, in C# code, I can easily fire the event that will make that item fade in and out in opacity—which is a joke to wire up in the ControlTemplate.

    I’m rambling at this point, but you get it…

    PostTypeIcon
    2,988 Views
  • The stakes are going up...

    Filed under:

    I think you should use the technology that makes sense when you build a solution. If this is ASP, fine. If this is Flash, fine. If this is WinForms, fine. I really don’t care. Each platform was created for a specific purpose, and probably still survives because it does it rather nicely.

    Interestingly enough, the number of cell phones sold each year outnumbers the total number of computers ever sold…So, you may ask why I haven’t jumped ship into the handset market. And, yes, I’m watching it very closely. But, for the most part, the technology just isn’t there to do anything interesting, yet. Simple animations are totally off-limits as it will eat the battery alive. Not to mention, the notion of a ‘Data Plan’ has yet to catch on as a commodity for carriers which means you have to spend an extra $20 a month just to get internet access. And, by now, you probably know that to have an interesting app, it must talk to the internet in some way. So…the technology and tooling just aren’t there yet, but it’s coming.

    What else is out there? AJAX? Most people hypothesize this huge value-add in AJAX, something unprecedented (Web 2.0?). But, I think most people are missing it. Asynchronous method calls from within a web page are useful if you want to drag-and-drop to a shopping cart or something. But, the real issue is this. What’s so wrong with a page refresh? The fact that internet connections are increasing at an exponential rate means that a page refresh is a joke. I can refresh the page in a blink. So, you may wonder whether AJAX is such a necessary rage. I don’t think so. Don’t get me wrong, I’ll put it in my tool belt and use it where I think it makes sense, but I don’t think it’s a reinvention of the web by any means.

    So, where do we go from here? Should I try to sneak in a pitch for Avalon, claiming the total reinvention of the client space? No—Avalon is not a new technology in the sense of old technologies. Avalon brings nothing new to the table other than this: it is a complete unification of the means to present and deliver a user experience. So, where is Avalon going to take you? Is it going to give you a new visual for your application? Maybe. Is it going to make the development of that visual easier? Maybe. But, contrary to popular belief, it is nothing more than that. There is definite power in Avalon. The problem is that most of the power is invisible. It is the fact that a truly emotional experience may be born into a software application without a technological barrier.

    So, to get to the point, the value in the next generation of software is not in the platform space anymore (we have reached that with Avalon). The power is in the design (Visual, navigation, interaction, etc). The problem is that software will continue to be designed in large part by software developers—who on the one hand will never understand the user, and on the other, will probably never want to understand them. So, the predicament lies in a compromise of sorts, which is never to the benefit of the user. When a group is able to turn a software product into something more than 1’s and 0’s, which is all it has been until this day, we will truly be surprised. I think Apple has made a lot of innovation in this space, but they are far from the magnitude I imagine.

    Good isn’t even close to good enough anymore. The line has been breached and there are going to be players left in the dark. You are faced with a simple decision, play in the new game, or don’t play at all. Do you know what it takes to make your application fun? How about sad? Or, what about powerful? Sure, I’m spouting off now, but these issues are something you should probably take note on.

    It’s going to be a hard market out there. Having a solid development team that is faster than lightning helps none, if you don’t have a rock star design group. Beside the point, you have to have someone who shits gold. Otherwise, you just won’t survive. As I keep talking, the stakes are going up...

    So, it’s going to be interesting to see who is on top next year, or the year after...

    PostTypeIcon
    1,379 Views
  • PDC 05 Event Calendar App

    Filed under:

     

    I sat down last night and tonight with the intention of building out a cool calendaring app with functionality to share events and invites with friends (maybe I'll get to that tomorrow night). I didn't finish because I was sidetracked on some bugs, but the sorting and filtering of the events works fine, and you can drag and drop the sessions onto the calendar. That all works fine... (You may even want to use it as a real calendar for the week, but that's up to you)

    Play around with it, nothing too much...

    Download

     

    PostTypeIcon
    1,084 Views
  • What is in a name? Obviously, not too much...

    Just because some marketing yuppie named the new apis WCF and WPF, doesn't mean that they have to be used in any shape or fashion.

    I personally get very annoyed when people use those terms over Indigo and Avalon. Realistically, the names will vanish in the future, being replaced by "I am programming Windows," but until then, stick with what it has always been...

    Thanks-

    PostTypeIcon
    1,186 Views
  • A lesser-seen value of XAML

    Filed under:

    So, I come to realizations every now and then...Here is one pertaining XAML.

    I have always know that XAML is a good visualization of source code because it allows you to inherently view the control hierarchy without having to look at another source. So, instantly you can glean the structure of your application.

    <Button>

          <Grid>

                <Image />

                <TextBlock />

          </Grid>

    </Button>

    But, more so, here is an even interesting point. In XAML you don't have to think about variable names (which in my case takes a lot of my time), because the structure of the XAML is self-documenting in that you don't need names. In the case you do, you create a very meaningful name and your off...

    PostTypeIcon
    2,022 Views
  • Creating custom controls, the real way

    Filed under:

       I know the question has been dodged, and I myself didn't have a firm grasp--but I am back to report on "the way" of creating a custom control.

       First of all, be aware that a custom control should be created only as a last option. For the sake of all the work that has gone into Avalon to make controls lookless, you should always evaluate the available controls before contunuing. I believe the true circumstance for a custom control is when you want to package certain ideas together with data. The key word being data. That is really the only reason you create a custom control--you want a common ancestor object without having to rewire the data hook-up everytime. A custom control is not for look-ability. Because, in that sense, you are destroying the lookless metaphor--which is undesirable. You always want that style-ability inherent in Avalon.

     

       Now you may recall the first step in creating an Avalon application with a custom control is to set the 'UICulture' property in the project settings. This is a temporary work-around for satisfying Avalon's taste for localized apps. To do this, navigate to the project settings file (It will be in the project directory, and called something like "<ProjectName>.csproj"). Open it up in Notepad and it should look like below. Add the bolded line.

       <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
            <PropertyGroup>
                 <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
                 <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
                ...
                <UICulture>en-US</UICulture>
            </PropertyGroup>
            ...
      </Project>

       

       The next step is to create class file (Widget.cs). The only difference between a regular class and this one is the 'partial' decorator. The 'partial' tells .NET that there is another part of this class in a separate fill.

          namespace ApplicationNamespace
          {
                public partial class Widget : ContentControl
                {
                }
          }

       Although you could inherit from a number of classes, ContentControl best satisfies the fact that we want a control with lookless behavior. In light of that, ContentControl is just a container. Essentially, this allows us the flexibility of the control to hold anything.

       Since XAML is the easiest language to describe Avalon elements, it would be a shame to stay in C#. So, go ahead and create a XAML file (Widget.XAML).

          <ContentControl x:Class="ApplicationNamespace.Widget"
                xmlns="http://schemas.microsoft.com/winfx/avalon/2005"
                xmlns:x="http://schemas.microsoft.com/winfx/xaml/2005"
                >

          </ContentControl>

       The above is the second half of the class declared in C#, which now enables us to fully work in XAML.

       Continuing on, let's add the custom control to the main Window (the stuff bolded is the important lines that hook it up):

          <?Mapping XmlNamespace="controls" ClrNamespace="ApplicationNamespace" ?>
          <Window x:Class="ApplicationNamespace.Window1"
                xmlns="http://schemas.microsoft.com/winfx/avalon/2005"
                xmlns:x="http://schemas.microsoft.com/winfx/xaml/2005"

                xmlns:cc="controls"
                >
                <Grid>
                      <cc:Widget /> 
                </Grid>      

          </Window>

      

       Now, go ahead and set some properties on the custom control:

          <ContentControl x:Class="ApplicationNamespace.Widget"
                xmlns="http://schemas.microsoft.com/winfx/avalon/2005"
                xmlns:x="http://schemas.microsoft.com/winfx/xaml/2005"       
                >

           <ContentControl.Style>

                  <Style>

                         <Setter Property="ContentControl.Width" Value="200" />

                         <Setter Property="ContentControl.Height" Value="200" />

                         <Setter Property="ContentControl.Background" Value="Red" />

                  </Style>

           </ContentControl.Style>

          </ContentControl>

       Run the application...You may notice that nothing is visible. The reason is that we did set the properties and we did create the custom control partial class in XAML, but it really isn't being connected with our real class in C#. The reason is that XAML really isn't a language and it must actually be converted into C#. To do this, we need to call InitializeComponent from the constructor of the Widget class:

          namespace ApplicationNamespace
          {
                public partial class Widget : ContentControl
                {

                      public Widget()

                      {

    InitializeComponent();

                      }
                }
          }

     

    Even now if you run the application the control won’t show up. The reason is that we may have specified dimensions and a background, but the control cannot set those on content that doesn’t exist, yet. To add a look, we should provide a default template—which is a way of adding a look to our lookless control. The template can be ripped out or styled differently at any time by the application.

     

    <ContentControl x:Class="ApplicationNamespace.Widget"

        xmlns="http://schemas.microsoft.com/winfx/avalon/2005"

        xmlns:x="http://schemas.microsoft.com/winfx/xaml/2005"

        Width="200" Height="200" Background="Red"

        >

        <ContentControl.Style>

                <Style>

                        <Setter Property="ContentControl.Width" Value="200" />

                        <Setter Property="ContentControl.Height" Value="200" />

                        <Setter Property="ContentControl.Background" Value="Red" />

                     <Setter Property="ContentControl.Template">

                            <Setter.Value>

                                   <ControlTemplate>

                                          <Grid Background="{TemplateBinding Property=Background}">

                                          </Grid>

                                   </ControlTemplate>

                            </Setter.Value>

                     </Setter>

                </Style>

        </ContentControl.Style>

    </ContentControl>

                      

    Going back to the class, let’s add some data through a property WidgetData—which returns a simple string “Red”. This is the data we are going to expose with our custom control (the essence of it):

       public partial class Setter Property="ContentControl.Template">

                                <Setter.Value>

                                        <ControlTemplate>

                                                <Grid Background="{TemplateBinding Property=Background}">

                                                 <TextBlock TextContent="{Binding Path=WidgetData,RelativeSource=/TemplatedParent}" />

                                                </Grid>

                                        </ControlTemplate>

                                </Setter.Value>

                        </Setter>

    I am binding the value to the TextBlock.TextContent property. The reason I have specified RelativeSource as ‘/TemplatedParent’ is that the Binding statement will not have any data context without RelativeSource. There are a couple of other values which can be automatically determined by Avalon at runtime. They all start with a forward slash ‘/’ and refer to common paths. ‘TemplatedParent’ gets us the main element that the ControlTemplate is modifying—which is the Widget class.

                      

        xmlns="http://schemas.microsoft.com/winfx/avalon/2005"

        xmlns:x="http://schemas.microsoft.com/winfx/xaml/2005"

        xmlns:cc="controls"

        >

        <Window.Resources>

                <Style x:Key="WidgetStyle">

                        <Setter Property="Control.Template">

                                <Setter.Value>

                                        <ControlTemplate>

                                                <Grid Background="{Binding Path=WidgetData,RelativeSource=/TemplatedParent}" />

                                        </ControlTemplate>

                                </Setter.Value>

                        </Setter>

                </Style>

        </Window.Resources>

        <Grid>

                <cc:Widget Style="{StaticResource WidgetStyle}" />

               

        </Grid>

    </Window>

                         

    PostTypeIcon
    6,206 Views
  • Using BitmapVisualManager

    Filed under:

    I have had some trouble getting this working, and I am not sure why it is that cool (probably the same reason for my fascination with the VisualBrush), but here it is:

    <StackPanel Width="100" Name="stack4">

          <Button Name="button4" Click="button4Clicked" Background="Green" Height="25">

                <Button.Content>dsfasdfasdf</Button.Content>

          </Button>

          <Image Width="100" Height="25" Name="img" />

    </StackPanel>

     

    In code:

    private void button4Clicked(object sender, RoutedEventArgs e)

    {

          VisualOperations.GetChildren(this.stack4).Remove(this.button4);

          VisualOperations.SetOffset(this.button4, new Vector(0, 0));

          VisualOperations.SetTransform(this.button4, null);

          RenderTargetBitmap bitmap = new RenderTargetBitmap(100, 25, 1 / 96, 1 / 96, PixelFormats.Pargb32);

          BitmapVisualManager visual = new BitmapVisualManager(bitmap);

          visual.Render(this.button4);

          img.Source = bitmap as ImageSource;

          VisualOperations.GetChildren(this.stack4).Add(this.button4);

    }

                            

    You can obviously notice the stretching, and that is because I have a RenderTransform scaling by 6. So, the BitmapVisualManager renders the content at the original size.

                            
    PostTypeIcon
    2,507 Views
  • Rich Media Experiences Lacking

    Filed under:

       TV is neat because many things are hand coded with explicit pixel positions and absolutes that are composited together to get an intended effect that looks incredible and visually enjoyable.

       I once thought Avalon was also going to be neat because we could do similar things. Not the hand coding, though. Yet, I have found that applying animation transitions and niceties is hard--almost to the point where it is best to do it like TV. The grid panel is awesome, which you may remember is the opposite of what I thought before. But, It really allows for an incredible layout. Back to the point, though--when you want to add these custom animation transitions and effects, usually, no make that almost always, you have to break down those nice layouts and go to back to absolute positioning on the Canvas. You also have a big problem trying to get controls (and their shapes) clipped so as to not cover up functionality behind. This means you have to play a game of promoting and demoting things in the Z order--which I would think adds some un-needed overhead.

       The thing is that objects and shapes on screen should be able to fly around, link up, decouple, change Z order without having to change the panel children order, and transitioning between shapes easily. Exactly like things on TV. The channel I most want to mimic is MSNBC (the stock channel). They have cool things going on: background animations using 3D and blurring, polished look and feel, and presentation of both information and usefulness in the same package.

     

       I am not trying to rag on Avalon, because I love it. I mean, how could I criticize something that is superior to anything else in existence. I can't. But, on the same token it seems like trying to build these experiences that I want are harder than I would have thought.

       Here is something I want to do:

       Imagine I have a Window with a button in the middle (the button is gel styled). I want to click the button and have it so that the screen seamlessly transitions from being a button in the middle to a new form with many controls and information. I can imagine the button getting bigger until it is half the size of the new form, at which time the background fades from the button color to the new form color and the controls on the new form start to appear. This is a simple example of something I want to do (simple). But, I find this hard.

       Have the designers of Avalon thought of these scenarios? Like I said, I don't mean to criticize, but just bring it to the table...

    PostTypeIcon
    2,024 Views
  • Sizing Paths

    Filed under:

    I had a Path (System.Windows.Shapes.Path) that I wanted to show, but it wasn't exactly clear as to how I was going to size it because there aren't any dimension properties to modify.

    So, simple enough, I plopped it in-between some Viewbox tags, and I was able to size it to my requirements.

    <StackPanel Orientation="Horizontal">

       <Path Stroke="#000000" Fill="#000000" StrokeThickness="16" Data="M9,12.844v71l216,72l-217,72v71l290-144L9,12.844z"/>

       <Viewbox Width="30" Height="30">

          <Path Stroke="#000000" Fill="#000000" StrokeThickness="16" Data="M9,12.844v71l216,72l-217,72v71l290-144L9,12.844z"/>

       </Viewbox>

    </StackPanel>

    You can see the difference:

                                
    PostTypeIcon
    1,768 Views
< Previous 1 2 3 4 5 Next > ... Last »