Office 2010 Backstage OnShow callback contextObject

0
share
 

The signature for the Office 2010 backstage OnShow callback looks like so:

void Backstage_OnShow(object contextObject)

But I cannot find anywhere that documents what the contextObject is.

Well I can tell you – it’s the Window object that is hosting the backstage as shown. I’m guessing it’s an object because it will be the equivalent Window object in whichever Office application happens to be running.

Unknown OfficeId: HelloWorld

Undocumented Office Ribbon Callback functionality

0
share
 

I just stumbled on an undocumented feature of the getImage callback for the Office 2010 Ribbon (well, backstage actually)

The “official” callback signature is

Public System.Drawing.Bitmap GetImage(Office.IRibbonControl control) {}

Or sometimes

Public stdole.IPictureDisp GetImage(Office.IRibbonControl control) {}

I don’t know which is “best”, but if you return a Bitmap it sure is easier to work with.

Now back in Office 2007 there are a couple controls with a GetImageMso callback that allows you to provide an Office Control ID for a built-in image. This is lacking from any 2010 backstage controls.

Whilst doing some unpleasant native debugging to try to “figure out” what office expects in these callback delegates, I tried creating a GetImage callback that returned a string.

<?xml version="1.0" encoding="utf-8"?>
<customUI xmlns="http://schemas.microsoft.com/office/2009/07/customui" onLoad="Ribbon_Load">
  <backstage>
    <tab id="MyTabShare" label="Testing">
      <firstColumn>
        <group id="MyGroup">
          <topItems>
            <imageControl id="imageControl1" getImage="GetImage"/>
          </topItems>
        </group>
      </firstColumn>
    </tab>
  </backstage>
</customUI>
        public string GetImage(Office.IRibbonControl control)
        {
            return "hello world";
        }

I was really hoping for an error about a bad callback signature, possible including an exception in MSO.DLL that I could dig into…

Instead, I got this:

Really… So when GetImage returns a string, Office interprets it as an ImageMso? I had to try:

        public string GetImage(Office.IRibbonControl control)
        {
            return "WindowKeepOnTop";
        }

The result: SUCCESS!

So, at least for the Office 2010 backstage ribbon, the getImage callback has an alternate signature:

string GetImage(IRibbonControl control)

Where string is an Office Image Id (or the value you would place statically in imageMso).

Definitive complete list of Office Ribbon Callback Signatures for 2007 and 2010

1
share
 

Microsoft’s documentation for programming the Office Ribbon is pretty sparse at best. There are two pages you can get Callback signatures:
1. Customizing the 2007 Office Fluent Ribbon for Developers (Part 3 of 3)
2. Introduction to the Office 2010 Backstage View for Developers

Notice that neither of these documents sound like where you would expect callback signatures “part 3 of 3″, and “introduction to the…” Also, the backstage introduction article contains rehashes of most of the office 2007 callbacks in a painfully verbose fashion.

I am here to help.
How about an excel spreadsheet containing the callbacks, associated control, source (2007 vs 2010) and the signatures in 4 different languages? Did I mention the data is already in a table and sorted by callback name?

Here you go:
Full Office Ribbon Callback List
Update: I have uploaded this file to a public SkyDrive so it can be viewed online, since I have needed to make some changes:
Office Ribbon Callbacks

This document is not a control -> callback mapping. The typical use case is:
I am building Office customizations using xml.
I need to implement X callback, but do not know the signature.
I look up the callback by name, then make sure it is the correct one for my control.

Also, I didn’t quite finish reconciling some discrepencies between the 2010 and 2007 documentation – for example, in 2007 the getImage is supposed to return an IPictureDisp – which is a real pain in the butt. My experience showed that returning a bitmap worked anyway, and now the 2010 documentation says getImage returns System.Drawing.Bitmap. I have switched to using Bitmap because it is so much cleaner, but I figured I should leave them both in there.

I am open to suggestions – just trying to fill what I consider a documentation gap.

Pre Populate SharePoint Document Properties in a Word Document

0
share
 

The integration between SharePoint and Microsoft office contiunes to improve with every successive release, but as of Office 2010 and SharePoint 2010, there is still a bit of feature gap when it comes to automation.

When a document originates from within SharePoint it is not too bad – you have to do a little CustomXMLPart trickery to set the properties. But what if your file is a SharePoint virgin?

The adding a document to sharepoint adds at least 3 additional Custom Xml Parts to the Word Document – one of them big, complex and guid-filled. To generate these parts would be a bit of a nightmare.

Turns out, you don’t need all of the xml to pre-populate fields. Nor do you need any guids. Here is all the XML you need:

<?xml version="1.0"?>
<p:properties xmlns:p="http://schemas.microsoft.com/office/2006/metadata/properties" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:pc="http://schemas.microsoft.com/office/infopath/2007/PartnerControls">
  <documentManagement>
    <SharePoint_x0020_ColumnName>Text Value</SharePoint_x0020_ColumnName>
  </documentManagement>
</p:properties>

I will leave it to you to figure out the column names (hint – spaces become “_x0020_”).

Store that xml bit in a string (say, xmlString), and call Document.CustomXMLParts.Add(xmlString);
Now, when the document is saved to sharepoint, the fields will be pre-populated, all the appropriate xsd and guids updated, and the user gets no errors about missing required fields!

Changing the value of an editBox office Ribbon Control at runtime

0
share
 

When creating VSTO Add-Ins that customize the Office Ribbon, the visual Ribbon editor makes some tasks trivial. All Ribbbon controls can be accessed by id using intellisense. The RibbonEditBox.Text field can be directly queried and modified.
Everything changes when you create the RibbonXML directly.

You cannot directly query any of the runtime values on a ribbon control. You must use the OnChange callback to get the value in the box.

        public void OnChange(Office.IRibbonControl control, string text)
        {
        }

But what if you wanted to change the value of the editBox (aka change the text)? Say perform some validation, or formatting?

I tried casting the IRibbonControl object supplied by the callback to a RibbonEditBox object… This didn’t work.
I tried casting the control object as a Dynamic and accessing the “Text” property… No dice.
I looked for some means of getting the ribbon control so I could modify the Text value – nothing.

The solution:
(Which was surprisingly difficult to find)
There are three things you will need to do:
1. Within your ribbon’s class, make sure you are saving the IRibbonUI reference provided by Ribbon_Load to a private variable. I just call it “ribbon”
2. Implement the getText callback and a private string variable to hold the internal value for the editBox
3. Implement the onChange callback to perform validation, update the private variable, and use the IRibbonUI object to invalidate the editBox control. This triggers the ribbon to call the getText callback again, effectively updating the field.

An example:
This snippet when merged into the Ribbon class, will ensure that the text entered in an edit box ends with “of doom”

First, the ribbonxml part

<?xml version="1.0" encoding="UTF-8"?>
<customUI xmlns="http://schemas.microsoft.com/office/2009/07/customui" onLoad="Ribbon_Load">
  <ribbon>
    <tabs>
      <tab id="DoomedObjects" label="DoomedObjects">
        <group id="spg" label="Stuff">
          <editBox id="txtDoomed" label="Doomed" onChange="OnChange" getText="GetText"/>
        </group>
      </tab>
    </tabs>
  </ribbon>
</customUI>

And the c# for the Ribbon class

        private string textValue;
        private Microsoft.Office.Core.IRibbonUI ribbon;

        public void Ribbon_Load(Office.IRibbonUI ribbonUI)
        {
            this.ribbon = ribbonUI;
            textValue= "";
        }

        public void OnChange(Office.IRibbonControl control, string text)
        {
            if (!text.EndsWith("of doom"))
            {
                textValue = text + " of doom";
                ribbon.InvalidateControl(control.Id);
                //Only invalidating when the value needs to change. You could invalidate after the if block as well
            }
            else
            {
                textValue = text;
            }
        }

        public string GetText(Office.IRibbonControl control)
        {
            return textValue;
        }

Behaviour of Application.MailMergeAfterRecordMerge Event

0
share
 

The signature for the Application.MailMergeAfterRecordMerge event looks like this:

        void Application_MailMergeAfterRecordMerge(Word.Document Doc)
        {
        }

While I would have expected the Document referenced in the Doc parameter to be the newly created merged document, it is actually a reference to the document from which the merge occurred. In other words, it’s not really all that useful.

PreviewResults

Automate Word Mailmerge Preview Results

0
share
 

(Long story short: the property you need is ViewMailMergeFieldCodes. Set it to 0 to enable preview; -1 to disable preview)

The mail merge process in Microsoft Word is a bit of a bear to automate sometimes. I suppose I should be thankful that it can be automated at all, but there are bits of it that are very poorly documented, requring a bit of trial and error to work with. It doesn’t help that most Office interop documentation leans toward Visual Basic…

Anyway, today’s issue was attempting to programmatically Preview the results of a Mail Merge in a C# VSTO project, like the button in the ribbon:

Big surprise: Document.MailMerge doesn’t contain any properties or methods with the word “preview”

Turns out there is a property called ViewMailMergeFieldCodes that does what we need, but in reverse. Microsoft’s documentation states:

This property returns True if merge field names are displayed in a mail merge main document, and False if information from the current data record is displayed

Trouble is, the field is an int, not a bool! A little debugging to the rescue:
When this field is set to -1, Preview is disabled, and the field codes are displayed.
When set to 0, Preview is enabled, and the record data is displayed.

To switch the displayed record, change Document.MailMerge.DataSource.ActiveRecord.

Now if only there was an event that fired when the record changed…

On using a light bulb as a current limiter (and crude current meter)

0
share
 

If you search on Google for “light bulb current limiter” you should come across several articles, newsgroup and forum posts about the details of building one. (i.e. )

Essentially, you connect a incandescent light bulb in series with an outlet, so you can safely test a device that might be prone to blow a breaker, or draw so much current as to release magic smoke.

One common feature of many of these articles is the idea that the light bulb will “blow” if the device draws too much current. This is totally and completely false.

When a 60-watt light bulb is connected directly to mains, it will draw approximately 60-watts of power, or 500 milliamps at 120-volts. That is the maximum amount of power that it will permit to flow, and it will burn at full brightness.

When you connect a device in series with the light bulb, it is effectively acting as a resistor to the current through the light bulb. With a 60-watt bulb, a device that used 250-milliamps wired in series would cause the bulb to burn at about 50% brightness (although light bulb brightness as a function of current is non-linear so this is not entired true, this is just an example…)
Now let’s imagine a worst case scenario – what could be wrong with an electrical appliance that would cause it to draw the maximum amount of current? Why shorting the power cord of course.

If you short the power cord of a device attached in series with a light bulb, the circuit is 100% IDENTICAL to plugging the light bulb directly into the wall. Nothing blows up, nothing catches fire – the bulb limits the circuit to 60-watts.

So if you are testing an electrical device using a lightbulb current limiter, please be aware: the bulb will not stop the power if too much is used. It is up to you to know how much power your device should be using, selecting a light bulb of the correct wattage to prevent it from going above (or much above) this, and turning off the power if the bulb is burning at full brightness when it should not be.

rand_keys_mem

.NET multiple dictionaries with the same keys memory usage

0
share
 

I need to create some objects that will allow me to access columnar data by header name. The access looks something like this:

class ParentObj {
string[] columnNames;
ChildObj[] Children;
}

class ChildObj {
Dictionary<string, string> Items;
}

All the child dictionaries will have the same set of keys, matching the column list from the parent.

Now this particular object is going to be used on computers that are resource constrained, and could contain large quantities of data. My big concern was should I actually use separate dictionaries, or should I just store the values in an array, and lookup the column number from a single dictionary.

After trying both methods with very large random data, I found the memory usage to only increase 10megs using separate Dictionaries. Certainly not worth the added complexity of managing my own Dictionary implementation.

My next question was if the CLR was wasting a bunch of memory on a bunch of duplicate keys. CLR Profiler to the rescue!

I modifed my test program to be able to either use the same keys in all child objects, or use random keys as well. After making all the strings the same size, it was clear that .NET does not keep a separate copy of each of the duplicate strings around:

Object memory when all keys are the same:

Object Memory when the keys are random:

So in conclusion, using many dictionary instances with the same set of keys does not result in a significant amount of duplicate data in memory (or memory waste).

Getting the base Document from ThisDocument

0
share
 

When developing a document level Add-In in visual studio, you may have a need to pass the current document to another function. This is tricky, because ThisDocument cannot be cast to a document object.

Turns out, ThisDocument inherits DocumentBase, and has a property called InnerObject. This is the Document.

Go to Top