Excel RefEdit in C#
During the development of FlowBreeze 3.0, I wasted a lot of time mucking around with different approaches to emulating the RefEdit control from C#. If you’re not familiar with it, the RefEdit control looks something like this on a typical Excel form:
![]()
(btw, this is actually the after image. the range address would not be present until after the step in the next image.)
Clicking it, you can then select the range with your mouse, as such:

Looking around the net, I found two viable options that would work in C#. One was Gabhan Berry’s article How to code a .NET RefEdit Control. This is a nicely done control, but unfortunately it had two major drawbacks. First, it relied upon a DLL he had created to make working with Excel easier. Second, it was written from the perspective of someone working with Excel externally, whereas I was building a COM add-in. I try to avoid distributing third party libraries where possible – especially if I have to read through the license terms and make sure that I am allowed to distribute the library with a commercial application. The second issue isn’t a show stopper, but it was going to take a decent amount of code re-writing to get it to work with my application.
The other control I came across was RefEdit Emulation for .NET on Code Project. Like Gabhan’s control, this provides a range selector with a small footprint. The major down side, though, was that it only works for non-modal parent forms. This control may be usable on a modal form with a little more work, but by this time I had spent way more time trying to create a range selector then I had originally planned.
Application.InputBox to the Rescue
The old standby alternative to the RefEdit control has been the Application.InputBox() method. In this case, Application refers to the Excel application reference. Instead of the RefEdit range selector with the small footprint, you get a larger forms that looks like this:

The other drawback to the InputBox is that the parent control doesn’t automatically minimize. If you hide the parent before calling InputBox(), the range selector will not become the topmost form and receive focus. In order to activate the range selector, the user would have to notice the flashing menu item on their task bar. The same problem exists if you try to set the parent form’s window state to minimized.
In order to deal with this, I created a little utility function to resize the parent form to the minimum window size, and then “hide” the parent at the base of the Excel window, looking something like this:

Here is the sample code, including a calling button click event, the utility functions to return either the Excel.Range or the range address, as well as an all-purpose method to release COM objects. Due to the general suckiness of this blog format, you will probably need to copy and paste this into an editor to see the full width of the code.
#region ---- Select range ----------------------------------------
private void btnSelectRange_Click(object sender, EventArgs e)
{
string prompt = "Select the range";
string title = "Select Range";
try
{
string address = Utilities.PromptForRangeAddress(this, title, prompt);
if (!String.IsNullOrEmpty(address))
{
txtBaseShapeCell.Text = address;
}
}
catch
{
MessageBox.Show("An error occurred when selecting the range.", "Range Error");
}
}
#endregion
#region ---- static utility methods ----------------------------------------
// Requires:
// using System.Runtime.InteropServices;
// using System.Windows.Forms;
DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
private static extern bool GetWindowRect(IntPtr hWnd, out RECT lpRect);
[StructLayout(LayoutKind.Sequential)]
private struct RECT
{
public int Left;
public int Top;
public int Right;
public int Bottom;
}
public static string PromptForRangeAddress(Form form, string title, string prompt)
{
Size windowSize = form.Size;
form.Size = SystemInformation.MinimumWindowSize;
Point location = form.Location;
SetFormPositionForInputBox(form);
string rangeAddress = string.Empty;
Excel.Range range = null;
try
{
range = XL.App.InputBox(prompt, title, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, 8 ) as Excel.Range;
if (range != null)
rangeAddress = range.get_AddressLocal(Office.MsoTriState.msoFalse,
Office.MsoTriState.msoFalse,
Excel.XlReferenceStyle.xlA1,
Office.MsoTriState.msoFalse,
Type.Missing);
}
catch
{
throw new Exception("An error occured when selecting the range.");
}
finally
{
form.Location = location;
form.Size = windowSize;
MRCO(range);
}
return rangeAddress;
}
public static Excel.Range PromptForRange(Form form, string title, string prompt)
{
Size windowSize = form.Size;
Point location = form.Location;
form.Size = SystemInformation.MinimumWindowSize;
SetFormPositionForInputBox(form);
Excel.Range range = null;
try
{
range = XL.App.InputBox(prompt, title, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, 8 ) as Excel.Range;
}
catch
{
throw new Exception("An error occured when selecting the range.");
}
finally
{
form.Location = location;
form.Size = windowSize;
}
return range;
}
public static void SetFormPositionForInputBox(Form form)
{
int x = form.Location.X;
bool isSet = false;
try
{
System.Diagnostics.Process[] processes = System.Diagnostics.Process.GetProcessesByName("Excel");
if (processes != null && processes.Length > 0 && processes[0] != null)
{
RECT rect;
IntPtr ptrXL = processes[0].MainWindowHandle;
if (!ptrXL.Equals(IntPtr.Zero) && GetWindowRect(ptrXL, out rect))
{
form.Location = new Point(x, rect.Bottom - SystemInformation.MinimumWindowSize.Height);
isSet = true;
}
}
}
finally
{
if (!isSet)
{
form.Location = new Point(x, 0);
}
}
}
public static void MRCO(object obj)
{
if (obj == null) { return; }
try
{
System.Runtime.InteropServices.Marshal.ReleaseComObject(obj);
}
catch
{
// ignore, cf: http://support.microsoft.com/default.aspx/kb/317109
}
finally
{
obj = null;
}
}
#endregion
2011 Excel Version Survey
Time for a periodic update to the BreezeTree Excel version survey. The numbers are below and speak for themselves. The survey data was collected over the last six months, and the target audience was business users. Standard disclaimer: This is not a scientific poll – but without Microsoft publishing these numbers, it’s probably as good as any other estimate.

The data is below. The percentages are based on 1587 data points (otherwise known as people).
- Excel 2010: 35%
- Excel 2007: 57%
- Excel 2003: 6%
- Excel 2002: <1%
- Excel 2000: <1%
For comparison, here is the data from the 2009 Excel version survey.
- Excel 2007: 39%
- Excel 2003: 46%
- Excel 2002: 11%
- Excel 2000: 5%
Commentary
The latest survey shows that Excel 2010 adoption has grown rapidly and 2007 usage has continued to grow (it has probably peaked by now). Meanwhile Excel 2003 usage has fallen dramatically, and Excel 2000 and 2002 (aka, XP) are looking rusty around the bits.
Another way of looking at the data:
- Ribbon users: 92%
- Toolbar users: 8%
Microsoft Excel Version Survey – 2009
Posted by Nicholas in Excel, Excel 2007, Office 2007 on January 25, 2010
For the past few years I’ve been running surveys to see what version of Microsoft Excel people are running (and by extension, which version of Office). Before getting to the latest data, the standard disclaimer applies – this polling data is not scientific. The sample sizes are decent but the user base is skewed. The data is collected from FlowBreeze trial users, which tend to be business-oriented users, and of those, only a small percentage are polled. Also, FlowBreeze runs on Excel 2000 through 2007 on Windows only. So Mac users and Office 97 hold-outs are not represented, nor are users of Open Office and online spreadsheets.
So with that out of the way, let’s get to the data. The graph below of the last six months of 2009 shows that Excel 2007 makes up half the user base. The other half are holding out because they hate the ribbon. (Ha ha, just kidding!)

Excel Version Survey - 2nd half 2009
What’s striking about the most recent trend is the drop off of Excel 2000 and 2002 (XP). In the last two years, they fell from a combined 20% of users to less than 5% , and a big portion of that drop off was in the last six months. On the eve of Excel 2007′s release, Martin Green did a survey that showed Excel 2003 with just over 50% of the market, with Excel 2000 and XP making up most of the remainder. The early 2008 data points below show that Excel 2003 held the same market share after Excel 2007′s release, indicating that XL 2007 adopters had leapfrogged versions.

Excel Version Trend 2008-2009
If history is a guide, after Excel 2010 is released a small portion of adopters will be Excel 2000 and XP users upgrading older PC’s, another small portion will be Excel 2007 users who like to stay on the cutting edge, but the majority should be Excel 2003 users leapfrogging versions. I say “should” because it’s hard to make a prediction. On one hand, Excel 2003 is still a great piece of software, it doesn’t look dated, and a lot of people do not like the ribbon. On the other hand, users of older versions will face increasing pressure to be able to read the new file formats (esp. those w/o the Office 2007 compatibility pack). I wouldn’t be surprised if Excel 2010 had a slow adoption rate, but it will be interesting to see.
Updated Flowchart Symbols Overview
The Flowchart Symbols overview has been updated. The symbol descriptions are now color coded, updated, and grouped by type. Click here to read the full article.
Microsoft Excel User Data – 2009
Just a quick update to the earlier data on Microsoft Excel / Office user data (see Office Market Share by Version – 2008 Data for reference). For the first six months of 2009, the survey has collected 594 more data points (for a half-year total of 898), with the breakdown as follows:
- Excel 2000: 4.7%
- Excel 2002: 10.6%
- Excel 2003: 46.0%
- Excel 2007: 38.8%
And, for those of you who prefer visual data, here is the graph:

Commentary
The most stable group of users over the last year and a half has been the Excel XP (2002) users. The recent data indicates that Excel 2007 is cannibalizing market share from Excel 2003 and Excel 2000.
How To Lie With Graphs
If I have one pet peeve about newspapers, it’s how they represent data. So let’s do a pop quiz. Which graph in the image below shows the worse looking trend?
The truth is, they are three representations of the same trend.
Graph A is the most realistic. The Y-axis scale goes from 0 to 480 and the aperture is roughly square.
Graph B distorts the data to look worse than it really is by using a Y-axis scale from 340 to 480. This is a common trick that was used by tobacco companies to show the nicotine levels in their cigarettes versus competitors. Their cigarettes weren’t really much better than the competitors. They just made sure to have the Y-axis cross the X-axis at a point just below their nicotine level, giving the appearance that it was close to nothing.
Graph C has the opposite effect of Graph B. It distorts the data to make the trend look better than it really is. By elongating the X-axis, the downward slope isn’t as steep.
Of course, the Oregonian published one similar to Graph B this morning, showing the last 13 months of factory orders, per U.S. Census Bureau data. Every time I see a graph like that, I think the reading public is getting bamboozled. The data is accurate, but it’s been sensationalized. (And don’t get me started on the one-data-point trends they see in school test scores.)
Microsoft Office Market Share by Version – 2008 Data
[Note: new data added under Updates section below.]
I’ve decided to share some Excel user survey data in hopes that others find it useful. Trying to find data for the market share of the various versions of Microsoft Office products is hard. Microsoft doesn’t publish it, and the only references I find online are typically in articles about the just-around-the-corner ascendancy of open source alternatives. So I decided to run my own survey. For the past year, a random sample of FlowBreeze users has been polled to determine which version of Microsoft Excel they are using. What the data is:
- Microsoft Excel versions 2000, 2002 (XP), 2003, and 2007.
- FlowBreeze trial users.
- Windows only.
- Can be extrapolated to Microsoft Office versions, since Excel is typically sold as part of the Office suite.
- Represents primarily business users.
What the data isn’t:
- A survey of Microsoft Office vs. other office suits such as OOo or Google Docs. (FlowBreeze is an Excel add-in.)
- It does not include Microsoft Office Sharepoint.
- It does not include Mac Office. (FlowBreeze is Windows only.)
- It is not scientific.
(See notes after the graphs.)

Microsoft Office Version Stats - Graph 1
The graph below is the same data as above but in a stacked column.

Microsoft Office Version Stats - Graph 2
I didn’t create a raw data tabulation for publishing, but the following table shows the monthly percentages by version. (The total sample count is 1373 users.)

Microsoft Office Versions - % Data Table
Notes
- Total sample count: 1373.
- It is impossible to say whether the early trending is due to the migration toward Office 2007 or the non-scientific data gathering method.
- The adoption of Excel 2007 seems to have leveled off. One interpretation of this could be that business users that migrate, tend to migrate early.
Conclusions
The most salient point to me as an Office developer is seen in Graph 2. The user share for Excel 2000 is still roughly 10%. The world of Office development has been moving toward .NET (C# or VB.NET) for some time, but Managed COM Add-ins for Excel 2000 are not officially supported by Microsoft. Even developing Managed COM Add-ins that support Excel 2002 forward can be problematic, raising the hurdle to 20% of the Excel market.
Martin Green did a survey in 2006, showing the market share for Excel 2000, 2002, and 2003 to be 18%, 21%, and 54% respectively. His survey included pre-2000 versions as well as Office Mac, so the numbers don’t correlate exactly. But taking those figures as a rough benchmark versus the data above, it suggests that Office 2007 users leapfrogged from previous versions of Excel more than from Excel 2003.
Updates
This section will contain monthly updates to the data, as time permits.
January 2009 – sample size = 147
- Excel 2000: 4%
- Excel 2002: 11%
- Excel 2003: 54%
- Excel 2007: 31%
February 2009 – sample size = 157
- Excel 2000: 4%
- Excel 2002: 15%
- Excel 2003: 42%
- Excel 2007: 39%
Do Lean and Six Sigma Apply to Software?
Neil Davidson has an interesting post questioning the logic of trimming the fat in economic downturns. His isn’t the first blog post I’ve seen recently on the applicability of Lean to software development. As someone with an Industrial / Manufacturing Engineering background who now does programming, I bristle when I see production line concepts applied to software development, so I thought I would chime in on the topic.
There has been a push in recent years (mostly by consultants) to extend concepts from Lean and Six Sigma to service-based industries, but for the most part it doesn’t make sense. Production is deterministic. Work orders are scheduled, raw materials are pulled from stock and production workers have a standardized set of instructions for manufacturing a sub-component or finished good.
The typical work flow for a knowledge worker is not deterministic. You can’t pull a programmer’s brain from stock, run it through a 1-ton arbor press, and squeeze out code to fill an empty software kanban. And even in manufacturing there is a difference between high-volume, low-mix assembly and low-volume, high-mix assembly. Many of the techniques used in Lean, such as value stream mapping, don’t apply well to low-volume, high-mix production, let alone to non-manufacturing.
Another problem is the misuse of ‘Lean’, ‘Six Sigma’, and the combined ‘Lean Six Sigma’.
Lean is an offshoot of the Toyota Production System, created by Taiichi Ohno. He boiled it down to shortening the time between getting an order and getting cash by eliminating the seven common causes of waste in the process. This has been misinterpreted as cutting staff, as in “running a lean operation”. They’re not the same thing. The next time you see a CEO announcing that they are going to cut jobs as part of their Lean Six Sigma adoption, you can be pretty sure they have no clue what they are talking about.
I’ve seen other piss poor analogies of Lean applied to software as well. To give one example, some claim that rarely used features or commented out code are wastes of over-production. In manufacturing, when a new product is introduced, first it gets designed by an engineer. If it is a high-volume, low-mix environment, there’s typically a pre-production run to iron out the kinks. If it is a low-volume, high-mix environment, it often gets prototyped by one or more technicians, assembly workers, and engineers. If you have waste in a process, the prototyping stage is where you want to discover it – before production is ramped up – so it can be identified and eliminated. The problem with the software / Lean-waste analogy is that most code development is more like the prototyping stage than the manufacturing stage. You don’t write code once, then create the exact same code over and over again.
Six Sigma is a collection of tools for problem solving and quality improvement. Central to it’s theme is DMAIC – define, measure, analyze, improve, and control, and it relies heavily on statistical analysis. While it has been applied successfully to service based organizations where the procedures are very standardized, such as healthcare, it’s bit of a stretch to apply it to software development.
FlowBreeze 2.2 Released
Posted by Nicholas in FlowBreeze Release History, Product News on June 22, 2008
Version 2.2 of FlowBreeze Flowcharting add-in for Excel has been released. It has several new features and many minor usability improvements. Two of the features have come from customer requests – a Style Wizard, and Insert Branch tool.
The Style Wizard (shown below) lets you quickly apply formatting to an existing flowchart. You can make bulk edits to the font, style, or connector style. Or you can use the drop down selectors in the Symbol and Style columns of the grid to change individual shapes. (The Style Wizard is not available in FlowBreeze Basic Flowcharting Edition.)

The Insert Branch tool (shown below) provides a easy way to add tree / org chart structures to a flowchart. It allows you to add standard, left-hanging, and right hanging branches. Optionally, you can specify a label for the connector line of each branch.You can also set the shape type for each branch element and the spacing between branches.
The form is optimized for quick entry. When you hit the Enter key, the branch text and label will be added to the grid without having to tab over to the Add button. If the branch text and label fields are empty, hitting Enter again will close the form and generate the branches.

The bulk of the other changes were small improvements to other forms and a number of minor (but annoying) bug fixes.
Get Better Results by Flipping the Funnel
Posted by Nicholas in Business Process Improvement, The Business of Software on March 7, 2008
Working Backwards
Lately I keep running into instances where different worlds coincide with a common theme. The theme I’m running into lately is flipping the funnel. Sometimes when you hit a stumbling block, it helps to flip the funnel and work the problem backwards.
For example, consider these three topics:
1. Improving e-commerce sales.
2. Reducing manufacturing cost and lead time.
3. Bringing a software product to market.
Focus on Checkout
In the first case – selling products online – it’s a common mistake to work the process from the front end. The standard logic goes: get more traffic, which will result in more downloads, which will get customers to the purchase page, which will result in more sales.
When you start out, this makes sense. But once you have a steady level of traffic, driving more traffic is expensive. Then you must put more effort into optimizing the landing page to drive downloads. Then, you continually improve the product to drive visits to your checkout process. Then you get the improved revenues, right?
But if you look at it in reverse, you would start with your checkout process. According to Closed Loop Marketing, the average drop-out rate during the checkout process is nearly 60%. What if, instead of driving 10% more traffic to your site, you fine-tuned your checkout process to convert 10% more customers?
If you put advertising money into driving 10% more traffic, you will need to pay that every month. And not all the leads would be well qualified. But putting the effort toward improving your checkout process provides a bigger payoff. The visitors are pre-qualified (after all, they already were interested enough to click your buy button), plus the rewards will be felt long after the improvements are made.
Fishing in the Value Stream
In the second case, I’ve been re-reading Learning to See, a book about Value Stream Mapping. Value Stream Mapping is a tool to analyze manufacturing processes (and recently service-based processes) in order to reduce cost and lead time. The process steps are laid out from start to finish, but the analysis works in reverse order. This is an over-simplified description, but essentially you start with customer demand and work your way back upstream to determine what you need from the preceding process and identify areas to reduce waste.
Write the Press Release First
The third case has to do with my own efforts to develop a new product. I wrote the spec, then started developing to it. It’s hard to describe, but there was something missing. It just felt like bits and pieces of related functionality without any glue.
Then I came across an old blog post by Werner Vogels, CTO of Amazon.com. In it, he lays out 4 steps to the product definition process:
Step 1 – Write the press release. He says, “Writing a press release up front clarifies how the world will see the product – not just how we think about it internally.”
Step 2 – Write the FAQ.
Step 3 – Define the customer experience.
Step 4 – Write the user manual.
Normally, I’m like many developers who market there own products. The press release is practically an afterthought. After coding and testing is done, you want to say, “Phew! That’s a relief. I’m done.” But you’re not. There’s a lot of work left to do, and having to write the press release afterward hits you when you’re running out of steam.
So I took Werner’s advice and did steps 1-3. (OK, so I skipped #4. So sue me.) Honestly, I wasn’t expecting it to have a dramatic impact, but surprisingly it did. I was able to refine what my marketing message would be. In doing so, I was able to refine what the user experience would be in a way that was much more logical and congealed.
I was less impressed with writing the FAQ, because those questions are always contrived until you actually get asked real questions by real customers. But overall, I would definitely recommend steps 1 and 3. It’s one of those things that people read about then forget, but if you actually try it, you’ll be glad you did.
You Might Have Guessed This Was Coming
Yes, I’m currently revamping the BreezeTree checkout process. Not only do I want to improve conversions, but I also need a system that works better for multiple product offerings because I’m working on the product that I pre-wrote the press release for. And, of course, it just happens to be a Value Stream Mapping edition of FlowBreeze.
