Category: Excel | Mitja Bezenšek

Excel VSTO RGB Color bug

2014-08-05T09:45:04+01:00

One of the strangest bugs I found in VSTO for Excel is the one that deals with assigning colors to the RGB property of the ChartFormat object. The ChartFormat object is used in multiple places of Excel. Let’s look at an example:

Series series = Globals.ThisAddIn.Application.Selection;
series.Format.Fill.ForeColor.RGB = Color.Red.ToArgb();

For brevity’s sake let’s suppose that we have a series of a chart selected and we run the code above. One would expect that the color of the selected series would be set to red, but what happens is this:

And if we try to color the series blue then the result is red!

Red and Blue components of the RGB property are reversed

Since I intentionally used the red color that resulted in a blue series on the chart, some of you might have figured out the bug. But imagine yourself trying to apply some color from the middle of the RGB color range and consitently getting the wrong results.

Well the workaround is easy: just use a wrapper function that swaps the red and blue components of the color:

private void ApplyColorToSeries(){
    Series series = Globals.ThisAddIn.Application.Selection;
    series.Format.Fill.ForeColor.RGB = InteropColor(255, 0, 0);
}

public int InteropColor(int red, int green, int blue){
    return Color.FromArgb(blue, green, red).ToArgb();
}

After searching the web I found that this bug has already been mentioned on the StackOverflow. It is interesting that this has not yet been fixed in the newer versions of Excel. I have first stumbled upon this issue with the Excel 2007 interop library but it is still present in the current one. The only reason that comes to my mind is backwards compatibility with the numerous Excel solutions out there. So it seems we should just get used to it.

Update:

It seems that this is not an Excel interop bug. Apparently the reason for this strange behavior is that VBA has a different representation of colors. For more see the comments.

Excel's ActivePane Index property bug and a workaround

2014-07-23T10:20:04+01:00

In Zebra BI we are positioning our custom WPF forms on top of the Excel window in order to offer a richer and more contextual UI. Calculating the exact position for the forms is quite complex and painful, due to things like:

detecting the Excel window state and left edge position
calculating from points to pixels ¹
coping with the Windows DPI
taking Ribbon / Formula Bar / Excel version into consideration
serious lack of events on many of Excel’s objects
…

The last nail in the coffin were the Panes which also need to be considered when a user uses the Freeze Panes option, which basically splits the worksheet into 2 or 4 Panes. At first it seemed like a simple adjustment until I started digging into the object model and ultimately found out that:

ActivePane’s Index property doesn’t work correctly

According to the Excel Object Model specification the ActivePane property:

Returns a Pane object that represents the active pane in the window.

and you can:

Use the Index property to obtain the index of the active pane.

Here is a simple code that is used to display the index of the current ActivePane:

var window = Globals.ThisAddIn.Application.ActiveWindow;
var activePane = window.ActivePane;
MessageBox.Show(activePane.Index.ToString());

Let’s see it in action.

As you see when there are 2 panes it always returns 2 and when we have 4 panes it always returns 4. I’m guessing it is just returning the number of the panes :)

The workaround

I needed to determine in which of the Panes is the current selection so I started looking at the Panes members. The only promising one was the VisibleRange. I didn’t want to use the Excel function INTERSECT since is quite costly performance wise. I figured out that just comparing the Left property of the VisibleRange with the Left property of the current selection should be enough (the same for the Top property). So I came up with this:

private int GetPaneIndex(){
    Range selection = Globals.ThisAddIn.Application.Selection;
    var window = Globals.ThisAddIn.Application.ActiveWindow;
    var paneCount = window.Panes.Count;
    if (paneCount == 2){
        Pane secondPane = window.Panes[2];
        if (secondPane.ScrollRow > 1 
          && secondPane.VisibleRange.Top < selection.Top)
            return 2;   
        if (secondPane.ScrollColumn > 1 
          && secondPane.VisibleRange.Left < selection.Left)
           return 2;   
    }
    else if (paneCount == 4){
        Pane secondPane = window.Panes[2];
        Pane thirdPane = window.Panes[3];
        if (selection.Left < secondPane.VisibleRange.Left 
          && selection.Top < thirdPane.VisibleRange.Top)
           return 1;
        if (selection.Left > secondPane.VisibleRange.Left 
          && selection.Top > thirdPane.VisibleRange.Top)
           return 4;
        if (selection.Left > secondPane.VisibleRange.Left )
           return 2;
        return 3;
     }
     return 1;
}

This works just fine with Ranges and pretty much every Excel object that has Left and Top properties. You get the correct index of the ActivePane.

However, what you also get, are some triggered events as soon as you access the VisibleRange property. I have no clue why this happens. Even a simple assigment like var range = pane.VisibleRange; causes the active chart to get deactivated, which again caused quite a few additional problems that are beyond the scope of this post.

Since the PointsToScreenPixels method is bugged as well. ↩

The best way to get to know Excel Object Model

2014-03-24T21:10:04+01:00

I am starting a category called “excel Excel” which will contain useful tips and tricks for Excel. It will be mostly directed towards Excel developers and power users.

How do I [blank] in Excel?

StackOverflow is full of questions like:

“How do I change the color of a Chart Series in Excel in VBA / C#?”

While doing it manually is easy, the problem occurs when you wish to start talking to Excel from the code. This is not surprising, considering the number of different objects present in the Excel Object Model. One can spend an insane amount of time trying to figure out the exact five steps to reach the desired effect. It is easy to get lost in all the objects, and their methods and properties. Which is why I love the macro recording option.

After learning about it you will be able to do all the tasks you already know how to do manually in code as well. Well, almost all. I’ll write about this in a future post.

The primary use of macro recording is to automate repetitive tasks. You just start the recording, perform the task and stop the recording. After that you can replay the recorded macro as many times as you wish. And not only that, you can also see all the steps that were performed in code!

How to record a macro

First of all I recommend that you show the Developer ribbon tab. You can do this under File | Options | Customize Ribbon, where you need to check the Developer ribbon tab:

After enabling the tab you gain access to macro recording and viewing options. You are now ready to record your first macro:

Click on the Record macro button under Developer tab
Perform the selected task, like changing a color of a Chart Series
Stop the macro recording
View the results

As you can see at the end of the animation all of the steps that I performed during the recording are saved in the macro. It is now easy to find the object / property you need. I use this extensively, almost every day. It mainly serves as a way of finding the specific object / property to set, after which I use the Intellisense to explore the options a bit further.

Tip:

If you will be using the described technique as much as I do, I even recommend adding it to the Quick Access Toolbar. Click on the arrows in the Toolbar, Select More commands and then add Record macro and View macro commands to your Toolbar: