You could not find anything worthy just because there is no such thing. Please see my comment to the question. Even if some kind of "Excel control" existed, it would be a part of Office, not Windows, so it could not be a part of .NET FCL (Framework Class Library,
http://en.wikipedia.org/wiki/Framework_Class_Library[
^]).
I suggested you to simulate Excel-like behavior using
System.Windows.Forms.DataGridView:
http://msdn.microsoft.com/en-us/library/system.windows.forms.datagridview.aspx[
^].
As you tag the versions of .NET from 1.0 (however, I suggest you should not consider anything prior v.2.0), I'm not discussing WPF which was introduced in v.3.0.
In this way, you would need to develop functionality by yourself, with this component being close enough for spreadsheet application; and all you need for Excel interop would be data exchange. You can find enough of sample code from the article you found. If you have questions, you can also ask the author to answer them. If you load the page you've referenced in your question and locate "Comments and Discussions", you can click "Add a Comment or Question" to ask your question and give the author a chance to reply.
The alternative way could be using third-party open-source library working with Excel data format without the interop. For example, consider LibreOffice:
http://en.wikipedia.org/wiki/LibreOffice[
^],
http://www.libreoffice.org/[
^].
To use the source code in your .NET projects, you will need to use P/Invoke:
http://en.wikipedia.org/wiki/P/Invoke[
^],
http://msdn.microsoft.com/library/en-us/vcmxspec/html/vcmg_PlatformInvocationServices.asp[
^].
This CodeProject article can also be useful:
Essential P/Invoke[
^].
Alternatively to P/Invoke, you can use a mixed-mode project written in C++/CLI. It can contain unmanaged code, but you can wrap some code in "ref" managed classes or structures, and make them public to be accessible by other .NET assemblies. This way, the resulting executable module would become a .NET Assembly which you can use as any other assembly in your .NET project. Please see:
http://en.wikipedia.org/wiki/C%2B%2B/CLI[
^],
http://msdn.microsoft.com/en-us/library/xey702bw.aspx[
^],
http://www.ecma-international.org/publications/standards/Ecma-372.htm[
^].
Finally, I would recommend you to avoid MDI. You don't want the suffering from this outdated and inconvenient UI style and scare off your users. Do yourself a great favor: do not use MDI at all. You can do much easier to implement design without it, with much better quality. MDI is highly discouraged even by Microsoft, in fact, Microsoft dropped it out of WPF and will hardly support it. More importantly, you will scare off all your users if you use MDI. Just don't. I can explain what to do instead.
First, please see:
http://en.wikipedia.org/wiki/Multiple_document_interface#Disadvantages[
^],
How to Create MDI Parent Window in WPF?[
^],
as well as my past answers where I also explain what to do instead:
Question on using MDI windows in WPF[
^],
MDIContainer giving error[
^],
How to set child forms maximized, last childform minimized[
^].
—SA
Submit an article or tip