As part of my job I have been programming quite a bit of software, often including the development of a Graphical User Interface (GUI). In the time of MS DOS this was challenging in the sense that libraries to create a GUI were almost non-existent, nor were plotting libraries. If you then wanted to show graphical output in the form of a chart, and send this to a printer, you were in for a big surprise. On top of that, not just the code, but all the data too, had to fit in a 640kB memory space. This asked for complicated algorithms in case the data wouldn’t fit. Think for instance of routines for correlation of long vibroseis records with a reference signal.
At a later stage, in the wonderful world of 32-bit Windows, things got easier in the sense that code and data no longer lived in the same address space and one could allocate dynamic memory in the order of ~1GB without worrying about data or code pointer types (tiny, compact, large, huge) as was the case with MS DOS.
But anybody familiar with Charles Petzold’s famous book “Programming Windows” (or any of the other reference books) can tell you how cumbersome it is working with a message loop, dealing with all User Interface events, including keyboard accelerators in barebones MS Windows.
This is where Microsoft Foundation Classes (MFC) came to the rescue. MFC also provided a complete framework, with a document/view architecture, that enabled adding multiple views to a single document, and/or working with multiple documents, all open at the same time. Also a lot of UI controls were available under MFC, supported by many efforts on websites like CodeProject.com, SourceForge, GitHub and others. Working in MFC implied programming in C++, bringing the blessings of object oriented (and reusable) code development.
It’s a fact of life, that things don’t always work straight out of the box, and then having a powerful debugger at hand can be a real life saver. For that reason, I always prefer to work with a dual screen setup; one screen for the application being developed and one screen for the Integrated Development Environment (IDE), so they don’t interact in an unexpected way…
Over time MFC unfortunately got orphaned by Microsoft, in pursuit of more modern user interfaces such as Windows Forms, Windows Presentation Foundation (WPF) – and of late – the Universal Windows Platform (UWP). Both WPF and UWP are associated with programming in C# (managed code) under .NET, where UWP is tightly integrated with the Microsoft Store for code distribution.
Considering all of the above, and considering the world is moving quickly to 64-bit I have embraced the WPF platform, staying away from the Microsoft Store.
Please note that with projects such as Mono, and DotNet-core being rolled out as an open source developer platform (also available under Linux) working with .NET is no longer equal to “locking yourself completely in with Microsoft”. As a benefit working with 64-bit code, large data-structures can now be opened as memory-mapped I/O significantly speeding up data access.
More recently, I started to work with the Excel-DNA library. Excel-DNA is an independent project to integrate .NET into Excel. With Excel-DNA you can make native (.xll) add-ins for Excel using C#, Visual Basic.NET or F#, providing high-performance user-defined functions (UDFs), custom ribbon interfaces and more. Your entire add-in can be packed into a single .xll file requiring no installation or registration.
This proved to be a very powerful library to create functions that one wishes Excel would have had built-in. It comes with all the bells and whistles to make your UDFs appear as a native Excel function. Overall, it is a powerful and actively maintained library written by Govert van Drimmelen.
The first Excel extension, that I wrote using Excel-DNA, was the second iteration of “GeoLib“; a library of geophysical routines, that covers various topics, such as AVO, Fourier transforms and convolution, coordinate conversion, pore fluid functions, rock property functions, as well as tapers and wavelet functions. It is available at the download page here.
Recently, I completed the “TopoLib” library. This is a coordinate transform library maintained on GitHub, that uses the PROJ library to do all the hard work.
PROJ is a generic coordinate transformation software library that transforms geospatial coordinates from one coordinate reference system (CRS) to another. This includes cartographic projections as well as geodetic transformations.
It is written in C++, and it has a C++ API to make its functionality accessible to 3rd party software. Because Excel-DNA is based on C# and uses managed code, an extra layer is needed in between PROJ and TopoLib, to cement the two together.
This C# interface is supplied by SharpProj, written and actively maintained by Bert Huijben.
At present, the TopoLib library has been upgraded to use Proj 9.0.1, accessed via SharpProj 9.1.183. Several spreadsheets have been provided in the Samples folder on GitHub (source code).
The binaries in my download area have also been updated.