So why should I use MoXAML.

It’s occurred to me that you might be wondering why you would want to use MoXAML Power Toys, especially as it seems to add features that you’ve already got. In this post, I’m going to explain the rationale behind the different features, and give you a preview as to what’s coming up.

The Comment command. Well, currently you can comment your XAML code and it works OK if you do it once, but if you then attempt to comment over the block again, you get some problems. The following picture shows what the problem actually is.

It doesn’t look too good does it? The first Power Toy, the Comment command behaves slightly differently:

As you can see, multiple comments and it continues to behave. So, that’s the Comment command – I hope you like it.

The sister command of the Comment command is the Uncomment command, and it works it’s way back up through the comment tree to uncomment the commands.

The Make Notify Property converts automatic properties into full properties, implementing the INotifyPropertyChanged functionality.

So, where are we going from here? Well, one of the things I’ve missed since my MFC days is the AppWizard. I want to be able to automatically create applications with default toolbars, status bars and menus. So, MoXAML is going to allow you to add these to an application by default. Once added, your app will look like this (and yes, the status bar indicators are fully functioning, so the keys change as you press them and the date and time updates every second):

Another item that’s high on my priority list is a major refactoring so that you can add extra plugins to the code without having to touch the base code. You’ll be able to specify which window(s) you want the command to attach to, and which menu item to hook it up to, and the underlying system will do the rest. In this way, it will be easy for you to add new commands as you see fit.

As always, let me know what you’d like to see in future versions and keep your comments coming in.


7 thoughts on “So why should I use MoXAML.

  1. Good stuff! It’ll be worth checking out just for that status bar. 🙂

    Couple of points I’ve been meaning to make concerning the Comment command:

    First, it would be nice (and surely easy) to support comment insertion when nothing is selected. Yes, there are times when it is handy to use the commenting functionality to actually COMMENT something… you know, with words. 🙂 just insert “<!–/* | */–>” and put the cursor where the | is.

    Second, and relatedly, if you comment a block of code that has an embedded non-MoXAML comment, your algorithm completely strips the comment tags out of it and uncomments it (relative to the encompassing block). This one is a bit tricker to solve because it would involve checking to see if a comment is a MoXAML comment or an old-school one, and not just blindly stripping all instances of “<!–” and “–>” from the to-be-commented block.

    I’ll let you figure that one out. 😉

    Otherwise, looking forward to the next release. I use the commenting all the time!

    Okay I couldn’t resist. How about this:

    Instead of always inserting /* and */ into comments, only do that when it’s an embedded comment. In other words, search the text being commented for any case of <!– and replace it with /*, and likewise replace any instance of –> with */, then just wrap the whole thing in a regular xml comment. This will still allow for multi-levels of embedded commenting, and will naturally support encapsulated commenting of regular old xml comments.

  2. Another thing, because it’s driving me crazy, is the attribute commenting. Xml is very picky about what it allows inside a tag, and comments aren’t welcome, so unless we can figure out a way to put something inside a tag that is effectively ignored yet still compiles, the only other option is to move the attribute OUTSIDE of the tag and then comment it there.

    So this is my latest idea. Suppose the user selects some attribute(s) inside a tag and activates the “comment” feature. We could move that block to the nearest tag boundary, mark it somehow has “belonging to the previous tag” (so that MoXAML can recognize this when uncommenting) and comment it.

    So starting with:
    <Image Stretch=”None”>


    Highlighting and commenting the Stretch attribute would yield something like:


    The “@” symbol is just an example–I’m not sure what’s best. Anyhow, when uncommenting, MoXAML would check to see if the block being uncommented has that attribute indicator, and if so, would uncomment it and move it back inside the previously-occurring tag, by looking for either “/>” or “>”.

    It’s not perfect, because the commented attributes no longer appear directly inside the tag, but I think it would be obvious enough once you got the hang of it. Your thoughts?

  3. peteohanlon

    Logan – thanks for your comments. I haven’t been ignoring you, but I’ve been busy coding MoXAML all weekend. The AppWizard is coming on really well – and I’ve had a blast coding it up. Damn – I love this coding stuff.

    Anyway – I’ll have a think about the commenting, and see what I can come up with. The attribute idea is similar to one I’ve been having a play around with, but I haven’t got it quite right yet – so I haven’t put it into MoXAML yet. I’ve been using the # as the indicator, but I like the @ symbol in your example better.

  4. As I recall, ‘@’ is used in Xpath to mean an attribute, so it makes sense in that context. And it doesn’t appear to be legal in an attribute name.

    I too have been coding all weekend–almost ready to release my next app, OrangeNote, which will be my first full-fledged WPF app. 🙂

  5. Will do!

    Wow XAML Power Toys 3 has Silverlight support–awesome. I can’t wait to fiddle around with Silverlight when I get some time now that it supports the CLR.

    That, along with Amazon announcing support for Windows-based EC2 and it’s been a good month! I can just imagine running a Silverlight module on a web page hosted on a EC2 Windows server and interfacing with my custom back-end, all written in C#. 😀

  6. peteohanlon

    I’m writing a blog entry on using MoXAML and XAML Power Toys 3 to quickly produce databound Silverlight apps.

    BTW – in case you haven’t noticed, MoXAML 2 has been released.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s