Delay's Blog

Silverlight, WPF, Windows Phone, Web Platform, .NET, and more...

  • Delay's Blog

    Why didn't I think of that in the first place? [Windows Phone 7 Charting example updated to include reusable, platform-consistent Style and Templates]


    I've previously blogged about how to get the Data Visualization assembly from the Silverlight Toolkit/WPF Toolkit working on Windows Phone. It's quite simple with my Data Visualization Development Release 4 and the Windows Phone Developer Tools Beta because it's now as easy as adding a reference to two assemblies and then creating some charts! However, those charts start out with visuals meant for use with Silverlight running in the web browser (white background, etc.), not Silverlight running on Windows Phone (black background, etc.). One of the things I did in a previous post was to customize the appearance of the sample charts so they fit in better with the phone conventions. Because Charting has come up quite a bit with customers lately, I wanted to do a quick follow-up to help make things even easier to use!


    Sample in landscape orientation


    Accordingly, I've made the following improvements to the DataVisualizationOnWindowsPhone sample:

    • Created the PhoneDataVisualizationResources.xaml file. It contains a ResourceDictionary with PhoneChartStyle, PhoneChartPortraitTemplate, and PhoneChartLandscapeTemplate. These are the same basic custom customized Style and ControlTemplates from before, but now they're named according to the platform convention for resources and bundled in a single, self-contained XAML file. This makes it easy for customers to incorporate the Windows Phone look into their charting applications.
    • Modified the sample to merge the contents of PhoneDataVisualizationResources.xaml into the application-level ResourceDictionary via MergedDictionaries in App.xaml:
          <!-- Merge resources from PhoneDataVisualizationResources.xaml (Build Action=Page) -->
      With the customizations now located off in their own dedicated file, the Chart in MainPage.xaml is simple and uncluttered:
          Title="my activity"
          Style="{StaticResource PhoneChartStyle}">
          <!-- ... -->
    • Changed the fills for DataPoints to use a solid color instead of a gradient. The default Brush used to paint the inside of data points has a gradient effect which looks quite nice on the desktop, but that gradient exhibits noticeable color banding on the actual phone because the displays used for mobile devices are often incapable of displaying the full range of colors humans perceive. While it's possible to minimize the impact of this by dithering (here's a nice article that shows how), you don't get that for free. Because gradients aren't consistent with the "Metro" user interface guidelines anyway, I've made all the default colors solid (as seen in the image at the start of the post).
    • Switched to using standard phone resources (ex: PhoneForegroundBrush) where applicable so Charts automatically respect the current phone appearance. Specifically, this enables seamless support for the "Dark" and "Light" phone themes without any effort on the part of the developer/designer.
    • Customized the Legend Template to include a horizontal scroll bar when rendered (horizontally) in Portrait orientation. The default Legend for Landscape orientation already had a vertical scroll bar, so this change makes it possible to scroll long lists in both layouts.
    • Switched to the official Silverlight 3 System.Windows.Controls.dll assembly now that the platform supports using strongly-named assemblies.


    [Click here to download the updated Windows Phone 7 Data Visualization sample application.]


    Important: After downloading the ZIP file above, you should "unblock" it before extracting its contents to avoid warnings from Visual Studio: Security Warning, You should only open projects from a trustworthy source. and The "ValidateXaml" task failed unexpectedly. System.IO.FileLoadException: Could not load file or assembly .... Unblocking is a simple matter of right-clicking on the ZIP file, choosing Properties from the context menu, then clicking the "Unblock" button in the lower, right-hand corner of the resulting dialog and hitting "OK" or "Apply":

    Unblock button in Properties dialog
  • Delay's Blog

    If they build it, I will come (and link to it) [WPPFormatter plug-in now available for TextAnalysisTool.NET]

    I went public with TextAnalysisTool.NET a few years back - it's a handy tool for interactive log file analysis that's popular with people in many parts of the company. The introductory post has more background and detail, but this snippet from the README gives an overview:

    The Problem: For those times when you have to analyze a large amount of textual data, picking out the relevant line(s) of interest can be quite difficult. Standard text editors usually provide a generic "find" function, but the limitations of that simple approach quickly become apparent (e.g., when it is necessary to compare two or more widely separated lines). Some more sophisticated editors do better by allowing you to "bookmark" lines of interest; this can be a big help, but is often not enough.

    The Solution: TextAnalysisTool.NET - a program designed from the start to excel at viewing, searching, and navigating large files quickly and efficiently. TextAnalysisTool.NET provides a view of the file that you can easily manipulate (through the use of various filters) to display exactly the information you need - as you need it.

    And here's an animated GIF showing TextAnalysisTool.NET working with some MSBuild output:

    TextAnalysisTool.NET demonstration


    I don't talk about it in the introductory post, but one of the things TextAnalysisTool.NET supports is a flexible plug-in architecture for handling custom file formats. Here's what the included documentation says:

    TextAnalysisTool.NET's support for plug-ins allows users to add in their own code that understands specialized file types. Every time a file is opened, each plug-in is given a chance to take responsibility for parsing that file. When a plug-in takes responsibility for parsing a file, it becomes that plug-in's job to produce a textual representation of the file for display in the usual line display. If no plug-in supports a particular file, then it gets opened using TextAnalysisTool.NET's default parser (which displays the file's contents directly). One example of what a plug-in could do is read a binary file format and produce meaningful textual output from it (e.g., if the file is compressed or encrypted). Another plug-in might add support for the .zip format and display a list of the files within the archive. A particularly ambitious plug-in might translate text files from one language to another. The possibilities are endless!


    Over the years, I've been contacted by various people wanting to use the plug-in architecture to add support for specialized file formats. One of those people is Tomer Rotstein who recently released a WPPFormatter plug-in. (If the acronym "WPP" isn't familiar to you, you might start by reading the Windows software trace preprocessor entry on Wikipedia - it's the file format used by the event tracing infrastructure in Windows.) But Tomer has gone above and beyond what I ever had in mind - as you can see from the following screen shot of WPPFormatter's "open file" dialog:

    WPPFormatter demonstration

    I encourage people to read Tomer's post to get a full sense of what WPPFormatter does. There's a download link at the end of that post, so please try it out if it seems useful!


    And for those of you who aren't already TextAnalisisTool.NET users, please:

    [Click here to download the latest version of TextAnalysisTool.NET.]


    Aside: Tomer's accomplishment is even more notable when you realize that TextAnalysisTool.NET was the first .NET application I ever wrote and that it targets .NET 1.1 - from a time before there were generics, extensibility frameworks, and all the other goodness we've come to take for granted! Truth be told, the plug-in model for TextAnalysisTool.NET is downright wacky in some ways, so I congratulate Tomer on succeeding in spite of my goofy design. :)
  • Delay's Blog

    New phone bits, same pretty charts [Upgraded my Windows Phone 7 Charting example for the Windows Phone Developer Tools Beta]


    The recent release of the Windows Phone Developer Tools Beta introduces a variety of notable changes to the Windows Phone platform and I've been meaning to update my Data Visualization on Windows Phone sample so I could continue to refer people to it for educational purposes. (Just like I did when the April Tools Refresh came out.) I finally got some time and have updated the sample so it targets the Beta Tools and works "out of the box".


    Sample in portrait orientation Sample in landscape orientation


    [Click here to download the updated Windows Phone 7 Data Visualization sample application.]


    Rather than relying on an automated project upgrade, I simply diff-ed the existing project against a new project I created width the Beta Tools and made the necessary changes myself in Notepad. It was all pretty straightforward - here are the things that stood out for me:

    • App.xaml.cs: There's a lot more initialization code by default.
    • App.xaml: There's no longer a need to bake all those phone-specific styles into every application, so the default App.xaml is nearly empty (like it should be)! Also, the new PhoneApplicationService events are hooked up by default.
    • SplashScreenImage.jpg: An appropriately-named splash screen is now created and used automatically.
    • MainPage.xaml: The platform-specific Phone* assemblies and default namespaces have shifted around a bit. SupportedOrientations is now set in XAML instead of code.
    • DataVisualizationOnWindowsPhone.csproj: The WINDOWS_PHONE symbol is now #define-ed by default, giving shared code now a standard way of detecting the Windows Phone platform. The phone assembly references are slightly different and the splash screen is included by default.
    • WMAppManifest.xml: The property PlaceHolderString on the DefaultTask element has been renamed.

    While I was at it, I also tweaked the way the data source is created (by making it a class and moving it to the Resources section) so now the charts show up at design-time, too. I'm using the exact same System.Windows.Controls.DataVisualization.Toolkit.dll and System.Windows.Controls.dll assemblies as before (see notes 4 and 5 of the previous post for more context) - though there should no longer be a need to "un-sign" the Silverlight Toolkit assembly to use it on Windows Phone.


    This was all pretty basic stuff and it's important to note that none of the application code was affected. Changes like this are a natural part of the platform and project templates maturing - and it's great to see improvements like the default styles moving into the platform!

  • Delay's Blog

    Hopping outside the box [How to: Leapfrog Bindings (bridge DataContexts) in Silverlight and WPF]


    The data binding infrastructure for Silverlight and WPF is extremely powerful and makes it easy to write powerful, dynamic applications without worrying about synchronizing the UI with every change to the underlying data. By leveraging this power, developers can think entirely in terms of the data model and be confident that any changes they make will be reflected by the interface automatically.

    The way this works is that every element has a DataContext property, and the value of that property is inherited. DataContext can be assigned any object and acts as the default source for all Bindings applied to the element's properties. The object acting as DataContext can be as simple or complex as an application needs and is free to "shape" the data however is most convenient for the UI and Bindings. Collection-based controls like ItemsControl (and its subclasses ListBox, TreeView, etc.) automatically set the DataContext of their containers to the specific item they represent. This is what you'd expect and enables a great deal of flexibility when displaying collections. However, each element has a only one DataContext - so sometimes it's useful to "reach outside" that and bind to properties on some other object.

    The good news is that there's an easy way to leapfrog the DataContext and "bridge" the two elements! The trick is to use an ElementName Binding to point to that other element - then to root the Binding's Path at that element's DataContext and "dot-down" to the property of interest. An example should make things clearer...


    LeapFroggingDataContexts sample

    The sample above has an application-wide DataContext model object ApplicationViewModel containing a bool property ShowHeight that's TwoWay-bound to the CheckBox control. For convenience, ShowHeight is also exposed as a Visibility value via HeightVisibility - which is much more convenient to bind the Visibility property to. There's also a Mountains property containing a collection of MountainViewModel model objects. Each mountain in the list is meant to show or hide its height according to the setting on ApplicationViewModel - but because the DataContext of the ListBoxItem containers is set to instances of MountainViewModel, they can't "see" the HeightVisibility property... The most direct option is probably to propagate this value "down" to the MountainViewModel instances by adding a property to the class for that purpose and keeping it in sync with the "real" property on ApplicationViewModel.

    However, that feels like a bit of overkill for the current situation. Instead, if we just "leapfrog" the Binding in the item content, we can make use of the ApplicationViewModel directly and everything stays nice and simple!


    [Click here to download the Silverlight 4 source code for the LeapFroggingDataContexts sample.]


    Here's what it looks like in XAML:

    <UserControl x:Class="LeapFroggingDataContexts.MainPage"
            <local:ApplicationViewModel x:Key="ApplicationViewModel"/>
            DataContext="{StaticResource ApplicationViewModel}"
                <RowDefinition Height="Auto" />
                Content="Show height"
                IsChecked="{Binding ShowHeight, Mode=TwoWay}"/>
                ItemsSource="{Binding Mountains}">
                        <StackPanel Orientation="Horizontal">
                            <TextBlock Text="{Binding Name}"/>
                                Text="{Binding Height, StringFormat=' [{0:n0}m]'}"
                                Visibility="{Binding DataContext.HeightVisibility, ElementName=LayoutRoot}"/>

    ElementName points the Binding at an element with the DataContext of interest, then the Path selects the DataContext as a starting point (an instance of the ApplicationViewModel class in this case), hooks up to that object's HeightVisibility property - and we're done!


    While architectural purists might argue this technique is bad form, I've seen it come in handy for enough customer scenarios that it seems a worthwhile approach to keep in mind. Please don't abuse it - but feel free to use it! :)

  • Delay's Blog

    Spin Spin Sugar [Updated code to easily animate orientation changes for any Windows Phone application]


    A few weeks after the initial release of the Windows Phone Developer Tools in April, I blogged a sample showing how to easily animate device orientation changes for Windows Phone 7 applications. I noted at the time that the default behavior for application projects is no animation - the app immediately switches to the new orientation when the device is rotated (click here for a brief video of the default behavior). While this is clearly the simplest approach, I wanted to enable something a little fancier by smoothly animating the application's rotation from one orientation to another - just like the built-in applications do.

    To show what I'm talking about, here's a video of my implementation running on the emulator:

    Video of animated orientation change behavior

    FYI: The buttons in the video rotate the device one quarter turn clockwise or counter-clockwise. I begin by rotating counter-clockwise once, then clockwise once back to the starting orientation, then clockwise three more times to loop all the way around. And then show off just a bit. :)

    Note: I made that video back in April; the emulator looks a little different now, but the animation works just the same.


    As of yesterday's release of the Windows Phone Developer Tools Beta, some of the platform changes have invalidated my original implementation. But that's okay, because I've updated the code to work with the latest release - and made a few improvements along the way! :)


    [Click here to download the AnimateOrientationChanges sample for Windows Phone 7.]



    • [Please review the "Notes" section of my previous blog post for additional information.]
    • The implementation is now based off PhoneApplicationFrame which simplifies things a bit by avoiding the need to track state across pages. Conveniently, this also makes the setup process a bit easier. What's more, I was able to get rid of the TranslateTransform based on a suggestion by Seema Ramchandani, one of the Silverlight performance experts. And I've added a bit of code to avoid unnecessary calls to InvalidateArrange which helps free up a few extra CPU cycles.
    • One of my earlier concerns was that I hadn't been able to run code on actual Windows Phone hardware, so I wasn't sure the snappy performance I saw under the emulator carried over to the device. Fortunately, I've gotten access to an actual prototype and have verified the sample application runs quite smoothly in the real world, thank you very much. :)
    • That said, my sample is pretty simple - Seema expressed concern about possible slowness for the more complex layouts real applications might use. And while I share her concerns, the options for improving the situation in such cases all seem like they'll degrade the visual quality of the rotation animation. The current implementation gives the best quality it can on any device for any layout (and automatically degrades as necessary to catch up if it falls behind); the alternatives create animations that just won't be as smooth. :( So I'm reluctant to start down that path until I know it's necessary. Please let me know what your experience is - whether good or bad - so I can make an informed decision!
    • Here are the complete directions for adding rotation animation to a new application (if you're upgrading an existing application, please undo all the previous install steps first!):
      1. Enable support for orientation changes by making the following change to the XAML for the relevant PhoneApplicationPages (note that rotation is no longer enabled by default for new pages):
      2. Verify (by running in the emulator) the pages you expect to support rotation really do - if things aren't rotating at this point, trying to animate the rotations won't help. :)
      3. Add the AnimateOrientationChangesFrame.cs code file from the sample to your project/solution.
      4. Open App.xaml.cs and change the RootFrame initialization in the InitializePhoneApplication method (you may need to expand the Phone application initialization region at the bottom):
        RootFrame = new PhoneApplicationFrame();
        RootFrame = new Delay.AnimateOrientationChangesFrame();
      5. Done; rotations will now be animated! To customize the animation, use the Duration, EasingFunction, and IsAnimationEnabled properties which are all still present and continue to work as outlined in the previous post.
    • The phone emulator has an annoying bug where it frequently fails to notify applications about an orientation change that just happened. This problem has nothing to do with my code (you can reproduce it by enabling rotation for any application), but shows up regularly when playing around with the sample app in the emulator. When the orientation gets "stuck" like that, just rotate a few more times and things sort themselves out. (Fortunately, this problem does not exist on actual phone hardware!)
    • The PageOrientation.PortraitDown value remains unsupported with this release because the platform still does not support it.


    On the one hand, animating orientation changes is kind of a whimsical behavior to add to an application - but on the other hand, it helps to create the kind of pleasing, platform-consistent experience that users appreciate and enjoy. AnimateOrientationChangesFrame isn't going to turn a crummy application into a good one - but it just might add some polish to help turn a good application into a great one.

    I've had fun creating this sample - I hope you enjoy using it!

  • Delay's Blog

    Banana SplitButton [A WPF-specific fix for SplitButton and some code analysis improvements for the Silverlight version, too]


    I've previously written that one of my ContextMenu test cases for the April '10 release of the Silverlight Toolkit was to implement a quick "split button" control for Silverlight using Button and ContextMenu. Though it wasn't my goal to build a general-purpose control for widespread use, there's been a lot of interest in SplitButton/MenuButton and I followed up with a few fixes for the Silverlight version and "official" support for WPF.


    SplitButton and MenuButton


    That might have been the end of the story - until Fabio Buscaroli contacted me to report an issue he was seeing with the WPF version (follow our exchange here). At first, I thought the problem was related to the DataContext not inheriting properly - and while that was true, it wasn't the whole story! When Fabio told me the tweak for DataContext I'd suggested didn't solve his RoutedCommand scenario, I had a look at a simple example he posted and realized the DataContext problem was a symptom of a larger issue: that the ContextMenu wasn't a logical child of the SplitButton. As soon as I solved that problem, it fixed Fabio's scenario and the related DataContext issue I'd discovered during my own investigation.

    Aside: None of this applies to Silverlight because that platform doesn't expose the notion of a logical tree the way WPF does.


    While I was working on this fix, I noticed full code analysis wasn't enabled for the SplitButton assemblies; I turned it on and addressed the handful of warnings it generated. Most of the changes won't matter to you, but one of them will: the namespace for SplitButton/MenuButton has changed. These classes now live in the Delay namespace - which is consistent with the rest of the sample code I post to my blog. Upgrading existing projects to the latest code will require a tweak of the XAML's "xmlns:" prefix and/or a tweak of the code's "using" statements. Otherwise, there have been no behavior changes to the functionality of SplitButton on Silverlight or WPF, so everything else should continue to work the same as before.


    [Click here to download the complete Silverlight/WPF source code for SplitButton/MenuButton and the sample application shown above.]


    It's been great to see the positive response SplitButton and MenuButton have generated. Thanks for everyone's help trying these controls out, finding issues, and reporting them!

  • Delay's Blog

    Breaking up (lines) is (not) hard to do [Tip: Put XAML attributes and elements on multiple lines so the markup is easy to read and work with]



    Put XAML attributes and elements on multiple lines so the markup is easy to read and work with


    The last few tips have dealt with DependencyProperty issues. Now it's time for something completely different: XAML. While it's nice to pretend XAML editing can all be done in a design tool like Visual Studio or Expression Blend, I've always felt that XAML should be pleasant for people to work with, too. Therefore, it's worthwhile to establish a common approach to XAML formatting. What I find works well is to put attributes and elements on separate lines with a single indent for continuations and nesting. (Aside: I make an exception for elements with a single attribute to keep simple things compact.) I also tend to order properties according to importance, starting with the most significant ones and ending with the least. I consider the x:Name of an element to be the most important, so it typically comes first. Attached properties also rank high in my book and are usually next. After that, I tend to list common properties (ex: ContentControl.Content and TextBlock.Text) first and formatting properties (FrameworkElement.HorizontalAlignment and .Margin) closer to the end. In addition to keeping lines short and easy to read, this approach is very revision control-friendly - by which I mean that edits, adds, and removes all show up unambiguously. Sometimes people forget that markup is code, too - please treat it with the same respect and discipline. :)

    Good Example

        Content="Click me"
            <SolidColorBrush Color="Pink"/>

    More information

  • Delay's Blog

    Revisiting the Code Not Taken [Updated analysis of two ways to create a full-size Popup in Silverlight]

    Earlier this year I wrote about two approaches for creating a Popup to overlay the entire Silverlight plug-in. I began by showing the technique most people start with and then demonstrated a rather surprising side-effect of that approach. Here's the relevant screen shot:

    A quirk of handling the Resized event on Silverlight 3

    Unless you've read the original post, the problem may not be obvious - here's what I said at the time:

    But something is still wrong in the image above... If you look carefully, you can see that the browser zoom is set at 50% - yet somehow the image is sized correctly despite us not doing any work to handle the browser's zoom setting yet. How can that be? Hold on, Sherlock, there's another clue in the image: look at the size of the buttons. Yeah, those buttons are not the size they should be for the 50% zoom setting that's active (refer back to the previous image if you don't believe me). Those buttons are at the 100% size - wha??

    Aside: Hey, don't feel bad, it weirded me out, too. :)

    It turns out that when you attach an event handler to the Resized event, Silverlight 3 disables its support for browser zoom. The reason being that Silverlight 3 assumes the application has chosen to handle that event because it wants full control over the zoom experience (via ZoomFactor and Zoomed, perhaps). Now that's really kind of thoughtful of it and everything - but in this case it's not what we want. In fact, that behavior introduces a somewhat jarring experience because the graphics visibly snap between 50% and 100% as the Resized event handler is attached and detached.


    Well, that was then and this is now: I'm pleased to report that Silverlight 4 does not have the troublesome "hooking Resized disables browser zoom" behavior! Consequently, projects targeting Silverlight 4 are free to hook the Resized event without worrying that their browser zoom behavior will be compromised. Yay!

    Aside: Of course, projects targeting Silverlight 3 (or previously compiled for it) and running on Silverlight 4 will continue to see the same Silverlight 3 behavior. This is because Silverlight 4 maintains backward compatibility with previous versions to avoid "breaking the web" when a new version comes out. Specifically, applications written for version N of Silverlight are expected to run the same on version N+M - even when there have been changes to the relevant functionality after version N was released.


    Now that it's possible, I've updated the sample to demonstrate the desired behavior on Silverlight 4 by making the following tweak to the Application.Current.Host.Content portions:

    EventHandler rootResized = delegate
        child.Width = root.ActualWidth / root.ZoomFactor;
        child.Height = root.ActualHeight / root.ZoomFactor;

    Everything else remains the same, and now the Application.Current.Host.Content approach works almost as well as the Application.Current.RootVisual approach I recommended previously (though the image still flickers when changing the browser zoom):

    Correctly sizing the Popup to cover the plug-in


    With both approaches nearly equivalent on Silverlight 4, you might wonder if I'd like to revise my earlier recommendation to prefer the RootVisual-based approach... Well, I would not! I still feel the RootVisual approach is simpler and easier to understand, so I'll continue to use it myself and recommend it to others. However, there's no longer a compelling reason not to use the Content-based approach, so I'm cool if that's your personal preference. :)


    [Click here to download the complete source code for the original sample (a Visual Studio 2010 (Beta 2) project targeting Silverlight 3)]

    [Click here to download the complete source code for the new sample (a Visual Studio 2010 project targeting Silverlight 4)]

  • Delay's Blog

    SplitButtoning hairs [Two fixes for my Silverlight SplitButton/MenuButton implementation - and true WPF support]


    One of my ContextMenu test cases for the April '10 release of the Silverlight Toolkit (click here for the full write-up) was to implement a quick "split button" control for Silverlight using Button and ContextMenu. In that post, I cautioned that my goal at the time was to do some scenario testing, not to build the best SplitButton control ever. However, what I came up with seemed to work pretty well in practice and I figured folks could probably use the code mostly as-is.

    And it seems like they did - because I got two bug reports in that post's comments section! :)

    SplitButton and MenuButton


    Let me address them in reverse order:

    The position of the ContextMenu was wrong when the browser is zoomed: True enough - though I'm going to ask for a bit of leniency here because the cause of the misalignment is actually a bug in Silverlight (which I've already reported). It seems the results of a call to element.TransformToVisual(Application.Current.RootVisual) or element.TransformToVisual(null) are not consistent for elements that are vs. are not inside a Popup control when the browser is zoomed (in or out). As a result, the SplitButton code to position the menu got inconsistent data and was unable to place the menu correctly. I've tweaked the code slightly to accommodate the underlying issue and now the menu is properly aligned at any zoom setting.

    While I was at it, I figured it might be nice if the menu moved around with the SplitButton as the user resized the browser or changed the zoom while the menu was displayed. This is admittedly an edge case, but it's easy enough to handle by hooking the LayoutUpdated event while the menu is displayed (and only while it's displayed!), so I did that and now the menu sticks to the button and refuses to be shaken off. :)

    The code didn't work on WPF: I had a footnote claiming my Silverlight implementation should work on WPF as well, though I hadn't tried it myself. It turns out that statement is mostly true - except for the positioning logic which bumps into an subtle API incompatibility with the TransformToVisual method. (Noticing a pattern here?) In the process of getting things working for WPF, I realized the code to position the menu could be simplified somewhat with the (WPF-only) TranslatePoint method. Therefore, the actual positioning logic is a tad different across the two platforms ("a tad" == 4 lines of code) while everything else stays the same. This time when I claim SplitButton and MenuButton work on WPF, it's because I've tried it. :)

    In fact, I've added a new, WPF-specific assembly (SplitButtonWpf) and demo (SplitButtonWpfSample) to the sample code associated with this post. Which means there is a dedicated assembly containing SplitButton and MenuButton for both platforms as well as a separate sample application for each!


    [Click here to download the complete Silverlight/WPF source code for SplitButton/MenuButton and the sample application shown above.]


    With those changes in place (and an unrelated key handling tweak for WPF), I feel even better about the prospects of using SplitButton and MenuButton in a real application. Naturally, if something else comes up, please let me know. Otherwise, I hope you find it useful!

  • Delay's Blog

    The source code IS the executable, RTM edition [Updated CSI, a C# interpreter (with source and tests) for .NET 4 RTM]


    CSI is a simple C# interpreter and has been available for .NET 1.1, 2.0, 3.0, and 3.5 for a while now. Earlier this year, I updated CSI for .NET 4 Beta 2, and now I've (somewhat belatedly) updated it for the final, public .NET 4 Framework. Today's post is mainly about getting an official .NET 4 RTM-compiled build of CSI released, so there aren't any functional changes to the tool itself.

    FYI: I have a TODO list and there are some interesting things on it - it's just that none of them seemed particularly urgent.

    The links above explain what CSI is and how it works; the executive summary is that CSI offers an alternative to typical CMD-based batch files by enabling the use of the full .NET framework and stand-alone C# source code files for automating simple, repetitive tasks. It accomplishes that by compiling source code "on the fly" and executing the resulting assembly behind the scenes. The benefit is that it's easy to represent tasks with a simple, self-documenting code file that leaves no need to worry about compiling a binary, trying to keep it in sync with changes to the code, or tracking project files and remembering how to build everything.


    [Click here to download CSI for .NET 4.0, 3.5, 3.0, 2.0, and 1.1 - along with the complete source code and test suite.]



    • The copy of CSI.exe in the root of the download ZIP is now the .NET 4 version because that's the latest public .NET Framework. Previous versions of CSI can be found in the Previous Versions folder: CSI11.exe, CSI20.exe, CSI30.exe, and CSI35.exe.
    • As with the previous release, I have not re-compiled the .NET 1.1 version, CSI11.exe - largely because I don't have .NET 1.1 installed anywhere. :)


    Here's the "read me" file for a slightly better idea of how CSI works:

    ==  CSI: C# Interpreter                           ==
    ==  David Anson (  ==
    CSI: C# Interpreter
         Version 2010-06-07 for .NET 4.0
    Enables the use of C# as a scripting language by executing source code files
    directly. The source code IS the executable, so it is easy to make changes and
    there is no need to maintain a separate EXE file.
    CSI (CodeFile)+ (-d DEFINE)* (-r Reference)* (-R)? (-q)? (-c)? (-a Arguments)?
       (CodeFile)+      One or more C# source code files to execute (*.cs)
       (-d DEFINE)*     Zero or more symbols to #define
       (-r Reference)*  Zero or more assembly files to reference (*.dll)
       (-R)?            Optional 'references' switch to include common references
       (-q)?            Optional 'quiet' switch to suppress unnecessary output
       (-c)?            Optional 'colorless' switch to suppress output coloring
       (-a Arguments)?  Zero or more optional arguments for the executing program
    The list of common references included by the -R switch is:
    CSI's return code is 2147483647 if it failed to execute the program or 0 (or
    whatever value the executed program returned) if it executed successfully.
       CSI Example.cs
       CSI Example.cs -r System.Xml.dll -a ArgA ArgB -Switch
       CSI ExampleA.cs ExampleB.cs -d DEBUG -d TESTING -R
    CSI was inspired by net2bat, an internal .NET 1.1 tool whose author had left
    Microsoft. CSI initially added support for .NET 2.0 and has now been extended
    to support .NET 3.0, 3.5, and 4.0. Separate executables are provided to
    accommodate environments where the latest version of .NET is not available.
    Version History
    Version 2010-06-07
    Update .NET 4 (RTM) version
    Make .NET 4 version primary
    Version 2010-01-04
    Add .NET 4 (Beta 2) version
    Minor updates
    Version 2009-01-06
    Initial public release
    Version 2005-12-15
    Initial internal release
Page 7 of 28 (277 items) «56789»