Windows 8 RT feels like Windows on ARM. Microsoft would be wise to embrace that.

I just got the chance to play with a Surface RT tablet, and I’m actually feeling much more positive about it. My understanding was that RT devices would pretty much only run Windows-Store, aka “Modern”, aka Metro apps, with cursory access to the desktop.

Turns out, Windows RT CAN run desktop apps. It has notepad, it has calculator, it has the command prompt and the administrative command prompt. Office 2013 is a desktop app on RT. It would appear that the infrastructure for windows desktop applications is alive and well on Windows RT, but Microsoft has taken steps to prevent us (us being developers) from using it.

This will inevitably change. Whether Microsoft condones it or not, people will figure out how to compile and load windows apps on ARM. (I’m REALLY hoping Microsoft provides a permitted way of doing it…, but I’ll take a jailbreak if necessary)

 

When Microsoft allows people to freely develop and install apps of all kinds on their Windows 8 devices (ARM or x86), Windows may just reach the holy grail of platform independence… on their flagship desktop operating system.

 

I’m really hoping they realize how huge this could be – sure they make a lot of money taking a 30% cut from the Microsoft Store, but restrictions and fees will only slow platform adoption. Restricted, closed platforms is the norm on tablets. An open, familiar platform… THAT would be game changing.

 

Keeping my fingers crossed…

CRM 4.0: Programmatically Upload a Mail Merge Template

image

 

The Mail Merge Facility in Microsoft Dynamics CRM 4.0 works fairly well in most cases. It is at the same time a bit to complicated for casual users, and a bit too simplistic for power users, but at least in our environment it has been tweakable enough to be useful.

Like everything in CRM the Mail Merge Template is an Entity, and thankfully Microsoft permits it’s customization (without unsupported tweaking).

image

You can add custom attributes and relationships; you can customize the form and the views; you can trigger workflows when attributes change (although you cannot register a plugin against it without unsupported tweaking). The tricky fields – body, filename, documentformat – they are all read/write through web services (http://msdn.microsoft.com/en-us/library/dd903944.aspx). Meaning you can programmatically upload new templates… but how?

 

After Google failed me, I initially chose the reverse engineer approach. The contents of the body field looked like Base64 (ended with equals signs), and indeed was. I create a tool to download the existing templated, modify them slightly, then add them back.  I had a working solution, but as we approached golive I got cold feet about messing things up in production- what if I’m doing it wrong and something breaks?

A bit of digging with reflector led to the solution: internally, the attachment on a mail merge template is treated the same as the annotation entity, and Microsoft has an article explaining the correct way to upload an attachment here : Upload an Attachment

The paraphrased money line: “updateTemplate.body = System.Convert.ToBase64String(byteData)”;

Changing a Word Mail Merge Field in C#

The mail merge fields in Microsoft Word are actually just a specific type of the more general Fields. Fields can be used to make fill-in forms, autogenerated text, dates, etc… They typically are displayed surrounded by funny looking square brackets, like <<first_name>>.

Inside the Word Xml, the Field and the display value are stored separately – the field looks like “ MERGEFIELD User_Title “, then in a separate range, the display of “«User_Title»” is stored.

Using the Word Object Model, Document.MailMerge.Fields contains MailMergeField objects for each instance of a merge field. The .Code member contains the range object, of which the .Text member will contain the field code (aka “ MERGEFIELD User_Title “). If you do a replace on this text field, it will update the merge field, but the display will remain the same.

You next have to call Document.Fields.Update() to get the display matching.

Here is some code:

        private void RenameMergeField(Word.Document doc, string oldName, string newName)
        {
            foreach (Word.MailMergeField field in doc.MailMerge.Fields)
            {
                if (field.Code.Text.Contains(oldName))
                {
                    field.Code.Text = field.Code.Text.Replace(oldName, newName);
                }
            }
            doc.Fields.Update();
        }

The internets agree: Visual Studio 2012 is a usability disaster

billy-madison-e1300752649964
“Don’t put it out with your boots, Ted!”

 

Visual Studio is the fundamental tool used to create a good majority of the software for Microsoft’s operating systems, and has been for, well, a very long time. New releases tend to be inexorably linked to new language features or versions. Also typically, each new release has brought new features, and improvements to performance and usability.

With every new release of Visual Studio I have been party to, the upgrade was an improvement. .NET (aka 2003), 2005, 2008, 2010… I upgraded and never looked back (with the exception of the loss of VB6 perhaps… but it really did need to go).

Until Visual Studio 2012.

Maybe Microsoft thought forcing developers to develop in a low-fi tool would encourage good low-fi app design. Maybe they thought we needed a break from being productive. I don’t know.

They have removed WIDELY used features (setup projects anyone?), and dramatically uglified the interface. They have reduced the number of things that get code highlighting, and reduced the number of colors used to highlight. HOW COULD THAT POSSIBLY BE CONSIDERED A GOOD THING?

Go ahead, try searching Google for “Visual Studio 2012 looks”… here is what you will find:

image
(FYI: I’m pretty sure BING is filtering such suggestions – I just checked)

Top suggestions:
“Visual Studio 2012 looks horrible”
“Visual Studio 2012 looks like crap”

Top results?
“Visual Studio 2012 is ugly as hell” (Funny, because it’s a “deferred” Microsoft connect bug
Visual Studio 2012 is so ugly, I actually cried.

 

Does anybody know who is to blame for this? Given the pervasiveness of ugly in all of Microsoft 2012 products (seriously Microsoft, a touch-centric interface on a server operating system? What were you thinking?), you would think there must be somebody high up that deserves a flaming bad of poop…

Let’s just hope he (or she) takes it better than Sasquatch