Calling dll from excel

Modular Programming

As you recall from our computer programming lessons, one of the key concepts in good software design is modularity: breaking our code into functional subroutines or functions, each responsible for a specific task with a clear interface for calling it.

Once encapsulated in a self-contained function, this functionality can be re-used in many locations in your program. This improves the size, quality, maintainability and readability of your program. Also, without modular design, your program can only grow so much before you lose your arms and legs.

I’d go as much to say that a good modular design is one of the first signs I look for in judging the quality of a programmer.

Using Functions Outside of Excel

Expanding on the modularity concept, why limit ourselves to functions we coded in our VBA application? There are many functions out there already developed by others and proven robust and performant – why not break the boundaries of Excel VBA and consume them, or CALL them from our Excel VBA program?

Some of the things we would like to do can’t even be achieved without using an external function that is not part of Excel VBA or that we can write ourselves without consuming such a function.

Consider, for example, the need to control the Window properties (maybe size or position) of another application running on our Windows operating system, from Excel VBA. This Window is governed by the operating system and we have no access to it without calling a Windows function that has access to that Window and can manipulate it.

What is a DLL?

A DLL (Dynamic Link Library) is a package of functions/subroutines callable by other programs running in the Windows operating system.

Typically, a DLL file has the .dll extension, although other extensions are possible for certain types of files (e.g. .ocx for ActiveX controls).

Most of the Windows operating system functionality itself is implemented by DLLs, each calling and called by other programs. One such example would be the Comdlg32.DLL file, offering a function to open the File Open dialog box for selecting file(s) – a functionality needed by many programs running on Windows.

Almost every program that is installed on a Windows machine registers its own DLLs in the Windows registry.

Once a DLL is properly registered with Windows, its published functions can be consumed and called by any other program running on that machine, and that includes Excel VBA, of course!

Almost every program developed for running on Windows makes use of existing DLL files and contributes its own DLL files to the party.

For an elaborate discussion on DLLs, read this Microsoft article.

Calling a DLL from Excel VBA

In order to gain access to the functions/subroutines included in a DLL file, you need to first declare your intentions to do that, using the Declare statement.

If you intent to call the PlayMusic sub exposed by the (imaginary) FunActivities.DLL file, your declaration statement may look like this:

Declare Sub PlayMusic Lib “FunActivities” ()

If the PlayMusic sub expects arguments, the declaration must also include those arguments (passed ByRef by default):

Declare Sub PlayMusic Lib “FunActivities” (ByVal Duration as Long)

As with any declaration in VBA, you can precede the declaration with the Public or Private qualifiers to contol for the scope of the sub in your VBA project:

Public Declare Sub PlayMusic Lib “FunActivities” ()

Declaring a function is very similar, with the notable return type expected as with any function:

Private Declare Function CountPixels Lib “PixelsInfo” () As Long

Sometimes, a function name as exposed by the DLL may be in conflict with VBA or other variables used in your program. To circumvent this, you can specify a local name to reference that function by in your VBA program, instead of the original name as determined by the DLL developer. In this case, you will add the Alias qualifier to reference the original function name, while the declared name will be your own local flavor:

Declare Sub MyPlayMusic Lib “FunActivities” Alias “PlayMusic”()

Another way of referencing a function in the DLL, instead of by its published (or exported) name, would be by its index, or ordinal number, as defined by the developer. In this case, we must use the Alias qualifier and the “#” character to indicate an ordinal number:

Declare Sub PlayMusic Lib “FunActivities” Alias “#241”()

Referencing by ordinal number guaranties consistency even if the function name will be changed in future versions, but developers are very aware not to mess with function names in DLLs, and this way is rarely used nowadays.

For a complete and detailed explanation of the Declare statement, read this Microsoft article.

Calling a DLL Sub from Excel VBA Example

The following example is implemented in The Ultimate Excel Date Picker. If you got this neat perk already, you may be familiar with the following code, as the Date Picker comes with its VBA code open.

In developing The Ultimate Excel Date Picker, I needed to reference several DLL services, one of which is to simulate a keyboard TAB pressed.

I could have used the SendKeys() VBA function, but let me tell you – it has more promise than it delivers. I would not rely on this statement at all in any of my programs.

However, the Windows user32.DLL file offers a keyboard event sub, directly from Windows, not VBA. Here’s the declaration part I have:

#If VBA7 Then   

    Private Declare PtrSafe Sub keybd_event Lib "user32.dll" _

    (ByVal bVk As Byte, ByVal bScan As Byte, _

     ByVal dwFlags As LongPtr, ByVal dwExtraInfo As LongPtr)

#Else

    ' Code is NOT running in 32-bit or 64-bit VBA7

    Private Declare Sub keybd_event Lib "user32.dll" _

    (ByVal bVk As Byte, ByVal bScan As Byte, _

     ByVal dwFlags As Long, ByVal dwExtraInfo As Long)

#End If

And here’s the function implementing a TAB keypress. Two calls are invoked here, one for pressing the TAB key, another for releasing it:

Public Sub PressTab()

    keybd_event VB_TAB, 0, 0, 0

    keybd_event VB_TAB, 0, KEYEVENTF_KEYUP, 0

End Sub

The two Constants used are declared as usual at the top of the module:

Const VB_TAB = 9

Const KEYEVENTF_KEYUP = &H2

I know I know, you must be thinking: what’s that PtrSafe qualifier I did not talk about, and what’s the story with the “IF VBA7 clause and LongPtr… All about that in next week’s Blog post!

And to expand on registering the DLL on different computers.

Once you compile and build the above code on your development machine, if you have

The project properties Build tab, select Register for COM interop.

your Visual Studio output folder (usually binDebug) where the compiled *.dll is found will also have a *.tlb file.

This *.tlb file is a ‘Type Library’. And is needed by the client machine to understand the different ‘Types’ in your *.dll and to basically tell the client machine how to use it.

By setting the above ‘Register for COM interop’ — aswell as a *.tlb file being produced, the assembly(dll) is registered on your machine, and is therefore accessible.

In VBA you can now add this file as a reference by

VBA Editor -> Tools -> References -> Browse -> Select

this will allow you to then declare the classes found in your library.

Dim TestClass As Test
Set TestClass = New Test
MsgBox TestClass.HelloWorld

HOWEVER — if you want to then use your dll on a different client machine, you will have to use regasm.exe — to register the assembly(dll) on that machine.

This can be done by the command line,

regasm.exe

in this case

regasm.exe TestDll.dll

once you have registered the assembly on the new client machine, you will be able to access it by again adding a reference to its *.tlb

Hope this helps!

Introduction

It’s fairly straightforward to call a .NET Framework library directly from Excel on Windows, particularly if you are using Visual Studio.  You don’t need Visual Studio Tools for Office.  However there doesn’t seem to be an easy guide on the internet anywhere. The Microsoft documentation is quite good on the subject, but can be a little confusing. This article is an attempt to redress the situation.

This article was updated in May 2020 to cover the latest versions of Visual Studio and Excel.  The article was originally written in 2007 and will work with all versions of Visual Studio and Excel since that date.

.NET Core

The approach below will NOT work with any version of .NET Core or .NET 5.  The last version of .NET this walk through will work with is the .NET Framework 4.8.

A Basic Walk Through

We’ll start by walking through a very basic example. We’ll get Excel to call a .NET method that takes a string as input (for example “ World”) and returns “Hello” concatenated with that input string (so, for example, “Hello World”).

1. Create a C# Windows Class Library (.NET Framework) project in Visual Studio called ‘DotNetLibrary’. It doesn’t matter which folder this is in for the purposes of this example.

2. To call a method in a class in our library from Excel we need the class to have a default public constructor. Obviously the class also needs to contain any methods we want to call. For this walk through just copy and paste the following code into our default class file:

using System;
using System.Collections.Generic;
using System.Text;
 
namespace DotNetLibrary
{
    public class DotNetClass
    {
        public string DotNetMethod(string input)
        {
            return "Hello " + input;
        }
    }
}

That’s it: if you look at existing articles on the web, or read the MSDN help, you might think you need to use interfaces, or to decorate your class with attributes and GUIDs. However, for a basic interop scenario you don’t need to do this.

3. Excel is going to communicate with our library using COM. For Excel to use a COM library there need to be appropriate entries in the registry. Visual Studio can generate those entries for us.

To do this bring up the project properties (double-click ‘Properties’ in Solution Explorer). Then:

i) On the ‘Application’ tab click the ‘Assembly Information…’ button. In the resulting dialog check the ‘Make assembly COM-visible’ checkbox. Click ‘OK’.

ii) On the ‘Build’ tab check the ‘Register for COM interop’ checkbox (towards the bottom: you may need to scroll down).

If you are working with 64-bit Excel then you may need to set the Platform Target in the Build properties to x64: thanks to danh for a comment to this effect.

4. Build the library.  You need Visual Studio to be running as an administrator for this to work because it’s putting COM entries in the registry.  If it’s not just right-click your Visual Studio icon and ‘Run As Administrator’.

5. Now start Excel and open a new blank workbook. Open the VBA code editor.  This can be tricky to find: you have to get the Developer tab visible on the Ribbon if it’s not already set up. To do this click the File tab, then click Options, Customize Ribbon, and under ‘Customize the Ribbon’ make sure ‘Main Tabs’ is selected in the dropdown, and then check the Developer checkbox. Now click the Developer tab, then click Visual Basic.

6. We now need to include a reference to our new library. Select ‘References’ on the Visual Basic Editor’s ‘Tools’ menu. If you scroll down in the resulting dialog you should find that ‘DotNetLibrary’ is in the list. Check the checkbox alongside it and click ‘OK’.

7. Now open the code window for Sheet1 (double click Sheet1 in the Project window). Paste the VBA code below into the code window for Sheet1:

Private Sub TestDotNetCall()

Dim testClass As New DotNetClass

MsgBox testClass.DotNetMethod(“World”)

End Sub

8. Click anywhere in the code you’ve just pasted in and hit ‘F5’ to run the code. You should get a ‘Hello World’ message box.

Getting Intellisense Working in Excel

Whilst the VBA code above compiles and executes, you will discover that intellisense is not working in the code editor. This is because by default our library is built with a late binding (run-time binding) interface only. The code editor therefore doesn’t know about the types in the library at design time.

There are good reasons for only using a late-bound interface by default: with COM versioning libraries can become difficult with early-bound interfaces. In particular, if you change the early-bound interface by adding, for example, a method in between two existing methods you are likely to break existing clients as they are binding based on the order of the methods in the interface.

For similar reasons you are heavily encouraged to code your interface separately as a C# interface and then implement it on your class, rather than using the default public interface of the class as here. You then should not change that interface: you would implement a new one if it needed to change.

For more on this see:

https://msdn.microsoft.com/en-us/library/system.runtime.interopservices.classinterfaceattribute(v=vs.110).aspx

https://msdn.microsoft.com/en-us/library/system.runtime.interopservices.classinterfacetype(v=vs.110).aspx

However, we can build our library to use early bound interfaces, which means intellisense will be available. To do this we need to add an attribute from the System.Runtime.InteropServices namespace as below:

using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.InteropServices;
 
namespace DotNetLibrary
{
    [ClassInterface(ClassInterfaceType.AutoDual)]
    public class DotNetClass
    {
        public DotNetClass()
        {
        }
        public string DotNetMethod(string input)
        {
            return "Hello " + input;
        }
    }
}

If you change your code as above it will expose an ‘AutoDual’ interface to COM. This means it is still exposing the late-bound interface as before, but now also exposes an early-bound interface. This means intellisense will work.

To get this working:

1. Save your workbook and close Excel.  Excel will lock the DotNetLibrary dll and prevent Visual Studio from rebuilding it unless you close it.  Remember you need to save your new code module.  Unless you are using a version of Excel prior to Excel 2007 you need to change the type: save it as type Excel Macro-Enabled Workbook (*.xlsm).

2. Go back into Visual Studio, change the DotNetClass as shown above, and rebuild the library.  Note there’s a new ‘using’ statement as well as the attribute line.

3. Re-open your Excel spreadsheet.  Once again if you are using a recent version of Excel there is an extra step: you need to explicitly enable macros.  A warning bar will appear beneath the ribbon saying the ‘Macros have been disabled’.  Click the ‘Enable content’ button and that should disappear.

4. Get the VBA code window up again (see item 5 above).

5. Excel can get confused about the interface changes unless you re-reference the library. To do this go to Tools/References. The DotNetLibrary reference should be near the top of the list now. Uncheck it and close the window. Now open the window again, find the library in the list, and re-check it (trust me, you need to do this).

6. Now run the code and it should still work (put a breakpoint in the routine and hit F5).

7. Enter a new line in the routine after the ‘MsgBox’ line, and type ‘testClass.’. When you hit the ‘.’ you should get an intellisense dropdown which shows that DotNetMethod is available. See below.

Let me re-iterate that this works and is fine for development, but for release code you are better off using the default late binding interfaces unless you understand the full versioning implications. That is, you should remove the ClassInterface attribute from your code when you do a release.

Deployment

In the example here we are using Visual Studio to register our .NET assembly on the workstation so that Excel can find it via COM interop. However, if we try to deploy this application to client machines we’re not going to want to use Visual Studio.

Microsoft have provided a command-line tool, regasm.exe, which can be used to register .NET assemblies for COM interop on client workstations. It can also be used to generate a COM type library (.tlb) separate from the main library (.dll), which is considered good practice in general.  You can find regasm.exe in the .NET framework folder: C:WindowsMicrosoft.NETFrameworkv4.0.30319 or similar.

As usual with .NET assemblies you have the choice of strong-naming your assembly and installing it in the GAC, or of not strong-naming it and including it in a local path. If you have strong-named your assembly and installed it in the GAC all you need to do is bring up an administrator Visual Studio command prompt and run:

regasm DotNetLibrary.dll

If you have not strong-named your assembly you need to tell regasm.exe where it is so that it can find it to register it. To do this you need to run the command below, where c:ExcelDotNet is the path where DotNetLibrary.dll can be found. This works fine, although it will warn you that you should really strong-name your assembly:

regasm /codebase c:ExcelDotNetDotNetLibrary.dll

Note that you can unregister an assembly with the /u option of regasm.

For more detail on this see https://docs.microsoft.com/en-us/dotnet/framework/tools/regasm-exe-assembly-registration-tool

Debugging into .NET from Excel

You may want to debug from Excel into your class library. To do this:

1. Using Visual Studio bring up the Properties window for the class library.

2. Go to the Debug tab and select the ‘Start external program’ option under ‘Start Action’. In the textbox alongside enter the full path including file name to Excel.exe for the version of Excel you are using (usually in Program Files (x86)Microsoft OfficerootOffice16 or Program FilesMicrosoft OfficeOffice).

3. On the same Debug tab under ‘Command line arguments’ enter the full path including file name to your test workbook (the .xlsm file). Once you’re done it should something like below::

4. Now put a breakpoint in the code (in our example the sensible place is in method DotNetMethod) and hit F5 in the .NET project. The .NET code should compile and Excel should start with your workbook opened. If you now run the VBA code to call the .NET library again, as above, you should find that the code will break at the breakpoint you set in the .NET code.

Possible Problem with these Examples

One problem we have had with these examples is that Excel can get confused about which version of the .NET Framework to load if you have more than one version installed. If this happens you will get an automation error when you try to instantiate .NET objects at runtime from Excel. The .NET types will appear correctly in the Excel object browser.

The workaround for this is to tell Excel explicitly that the version of the .NET Framework that you are using is supported. To do this create a text file called Excel.exe.config and put it in the same directory as Excel.exe itself. The file should contain the text below (with the version number replaced with the .NET Framework version you are using):

<?xml version="1.0"?>
<configuration>
  <startup>
    <supportedRuntime version="v2.0.50727"/>
  </startup>
</configuration>

References:

Index page from MSDN

https://docs.microsoft.com/en-us/dotnet/framework/interop/exposing-dotnet-components-to-com

More on COM Interop from COM clients into .NET:

https://www.codeproject.com/Articles/7587/Exposing-COM-interfaces-of-a-NET-class-library-for

Guidelines for COM Interoperability from .NET

https://blogs.msdn.microsoft.com/heaths/2005/03/09/guidelines-for-com-interoperability-from-net-2/

Excel/.NET versioning problems

http://krgreenlee.blogspot.com/2006/01/software-running-excel-with-net-11.html

FUNCTION  FRICTIONFACTOR (ROUGHNESS, DIAMETER, VELOCITY,VISCOSITY)
    !DEC$ ATTRIBUTES DLLEXPORT:: FRICTIONFACTOR

    !-----------------------------------------------------------------------------
    !Calculates the friction factor of a pipe using Churchill's equation (1977).
    !This equation is valid for all types of flows (from laminar to turbulent).
    !
    !Written By:    Christos Samaras
    !Date:          21/03/2014
    !E-mail:        [email protected]
    !Site:          https://www.myengineeringworld.net
    !-----------------------------------------------------------------------------

    IMPLICIT NONE

    !Declaring the necessary variables.
    REAL*8::  FRICTIONFACTOR,ROUGHNESS, DIAMETER, VELOCITY, VISCOSITY ,REYNOLDS, A, B, C, D

    !Calculate the Reynolds number (diameter in m, velocity in m/s, kinematic viscosity in m2/s).
    REYNOLDS = (DIAMETER * VELOCITY) / VISCOSITY

    !Calculate the intermediate variables A and B.
    A=((2.457 * LOG(1. / ((ROUGHNESS / (3.7 * DIAMETER)) + ((7. / REYNOLDS) ** 0.9)))) ** 16)
    B = (37530. / REYNOLDS) ** 16.

    !Apply the equation.
    FRICTIONFACTOR = 8. * ((((8. / REYNOLDS) ** 12.) + ((A + B) ** (-3./2.))) ** (1./12.))
    
    RETURN

END FUNCTION FRICTIONFACTOR

SUBROUTINE DOUBLEARRAY (ELEMENTS, INARRAY, OUTARRAY)
    !DEC$ ATTRIBUTES DLLEXPORT:: DOUBLEARRAY

    !---------------------------------------------------------------------
    !Receives as input a one-dimensional array and it doubles tis values.
    !
    !Written By:    Christos Samaras
    !Date:          23/03/2014
    !E-mail:        [email protected]
    !Site:          https://www.myengineeringworld.net
    !---------------------------------------------------------------------
    
    IMPLICIT NONE
    
    !Declaring the necessary variables.
    INTEGER*4, INTENT(IN) :: ELEMENTS
    INTEGER*4, INTENT(IN) :: INARRAY(ELEMENTS)
    INTEGER*4, INTENT(OUT) :: OUTARRAY(ELEMENTS)
    INTEGER*4:: I
    
    !Double the values of the input array.
    OUTARRAY = 2*INARRAY

    RETURN

END 

!DEC$ ATTRIBUTES DLLEXPORT:: FRICTIONFACTOR
!DEC$ ATTRIBUTES DLLEXPORT:: DOUBLEARRAY  

Option Explicit
Option Base 1

'---------------------------------------------------------------------------
'This module contains two examples of calling a FORTRAN dll from Excel/VBA.
'The first one uses a FORTRAN function straight from the worksheet,
'while the second one calls a FORTRAN sub from a VBA sub.

'Written By:    Christos Samaras
'Date:          25/03/2014
'E-mail:        [email protected]
'Site:          https://www.myengineeringworld.net
'---------------------------------------------------------------------------
                
'Declaring the function and the sub from dll file.
'NOTE: if the dll file is NOT in the same folder with the workbook, use its full path instead. Example:
'Public Declare Function FRICTIONFACTOR Lib "C:UsersChristosDesktopMySample.dll"
Public Declare Function FRICTIONFACTOR Lib "MySample.dll" _
                            (ROUGHNESS As Double, _
                            DIAMETER As Double, _
                            VELOCITY As Double, _
                            VISCOSITY As Double) As Double

Public Declare Sub DOUBLEARRAY Lib "MySample.dll" _
                        (ELEMENTS As Long, _
                        INARRAY As Long, _
                        OUTARRAY As Long)

Sub CallDoubleArray()

    'Declaring the necessary variables.
    Dim i           As Long
    Dim LastRow     As Long
    Dim ArrayIn()   As Long
    Dim ArrayOut()  As Long
             
    'Activate the Sub sheet and find the last row.
    With Sheets("Sub")
        .Activate
        LastRow = .Cells(.Rows.Count, "B").End(xlUp).Row
    End With
    
    'If there is at least one value proceed.
    If LastRow >= 4 Then
        
        'Resize the arrays.
        ReDim ArrayIn(1 To LastRow - 3)
        ReDim ArrayOut(1 To LastRow - 3)
        
        'Populate the input array.
        For i = 4 To LastRow
            ArrayIn(i - 3) = ActiveSheet.Range("B" & i)
        Next i
        
        'Call the FORTRAN Sub.
        Call DOUBLEARRAY(LastRow - 3, ArrayIn(1), ArrayOut(1))
        
        'Pass the results back into sheet.
        For i = 4 To LastRow
            ActiveSheet.Range("D" & i) = ArrayOut(i - 3)
        Next i
        
    Else
        
        'Empty column, inform the user.
        MsgBox "Please enter at least one value on B column and retry!", vbExclamation, "No data"
        ActiveSheet.Range("B4").Select
        
    End If

End Sub 

Option Explicit

Private Sub Workbook_Open()

    ChDir (ThisWorkbook.Path)
    Application.CalculateFull

End Sub 

Public Declare Function FRICTIONFACTOR Lib "C:UsersChristosDesktopMySample.dll" 

Call DOUBLEARRAY(LastRow - 3, ArrayIn(1), ArrayOut(1)) 

Page last modified: October 1, 2021

Add Content Block

In the last blog post, we created a simple dynamic link library for Windows that was easily callable from C, including Microsoft’s Visual C++. As stated in the article, the resulting DLL was entirely standards-compliant: it utilized proper calling conventions and it exported the functions we wished to expose. Therefore, we can take another step and call said DLL from Microsoft Office Excel.

Excel spreadsheets are often used for data analysis, and, occasionally, when non-trivial analyses are necessary, Fortran may make life a bit easier. Our Fortran DLL contained three functions for computing three types of averages, but countless, more complicated use cases exist. To keep this explanation simple, though, we’ll proceed with interfacing with our averaging procedures.

A Fortran DLL, or any DLL for that manner, isn’t directly interfaced with Excel. We first need a small amount of glue in the form of Visual Basic for Applications, or VBA, code. This BASIC code is necessary to define the interface to the DLL, transform the input data properly, and expose functions to the Excel worksheet. To get started on writing this glue, we need to open Excel’s VBA editor, accessible either with the Alt-F11 hotkey or clicking «Visual Basic» under the Developer menu. This should open the Visual Basic for Applications editor:

Next, we’ll need a new «Module» for our routines, which can be added by selecting «Module» from the Insert menu. This option should present a BASIC editor for defining our routines.

The first step is to create prototype calls for our Fortran subroutines. Recall our definition of the mean subroutine was:

      function mean(xc, n) bind(c)
      use ISO_C_BINDING
      implicit none
cGCC$ ATTRIBUTES STDCALL, DLLEXPORT :: mean

      real(kind=c_float)::mean

      type(c_ptr), value::xc
      integer(kind=c_int), value::n

The equivalent VBA declaration would be:

Private Declare PtrSafe Function mean Lib "C:workspaceExcelDllfortran-library.dll" _
    (ByRef x As Single, ByVal n As Integer) As Single

The above prototype has a few details that require explaining. First, we’ve declared this function with the «PtrSafe» attribute as required by 64-bit Excel; if a user is running 32-bit Excel, this attribute should not be included. Second, the prototype includes the full path to the DLL in question, and this path should be changed appropriately. Third, our array, x in the VBA prototype and xc in the Fortran function declaration, is not declared as an array in VBA. Rather, when using the «ByRef» attribute, we’re effectively passing the memory address of the first element of the array. Subsequent elements are assumed to be stored immediately after the first in a true C-compatible, one-dimensional array, so the above is sufficient. Visual Basic for Applications treats arrays somewhat differently than C does, so we’re not using a true VBA array as a parameter.

Our remaining Fortran functions are prototyped in VBA as:

Private Declare PtrSafe Function median Lib "C:workspaceExcelDllfortran-library.dll" _
    (ByRef x As Single, ByVal n As Integer) As Single

Private Declare PtrSafe Function mode Lib "C:workspaceExcelDllfortran-library.dll" _
    (ByRef x As Single, ByVal n As Integer, ByRef y As Single) As Integer

To use our functions on a spreadsheet, we need to create some VBA functions to call these routines properly and format the data accordingly. Taking the mean function as our initial example, we would want to define a worksheet-callable function, wsMean, as such in VBA:

Function wsMean(x As range) As Single
    Dim n As Integer
    Dim p() As Single

    p = Range2Array(x, n)

    wsMean = mean(p(1), n)

End Function

A worksheet function for computing the mean will accept a range of cells and return a single mean value for these given cells. The first step, though, is to convert the range of cells to a true VBA array. In our case, we can write a small, reusuable function that accepts a range and returns a one-dimensional array of values, Range2Array:

Function Range2Array(x As range, n As Integer)
    Dim res() As Single
    n = x.Rows.Count

    ReDim res(1 To n)

    For irow = 1 To n
        res(irow) = x.Cells(irow, 1).Value
    Next irow

    Range2Array = res
End Function

Much of the code above is specific to Excel and VBA, but it is basically reading the value of each cell and assigning each cell’s numeric value to an element of a properly-sized array. One might note that this routine only translates a single column. The user, though, can quickly extend this to multiple columns.

Returning to our wsMean wrapper, the call to the Fortran mean routine was:

wsMean = mean(p(1), n)

We appear to be passing only the first element of the array. However, recall that the function definition actually declared this argument as «ByRef,» meaning that VBA should pass the address of this argument, which is also the address of our entire array p. Therefore, our Fortran routine will receive the equivalent of a C pointer to a block of memory containing our one-dimensional array.

The median function can be wrapped accordingly:

Function wsMedian(x As range) As Single
    Dim n As Integer
    Dim p() As Single

    p = Range2Array(x, n)

    wsMedian = median(p(1), n)

End Function

Note that wsMedian is written nearly identical to wsMean since they both accept an array and a length, and return a single number. Our Fortran mode function is slightly more complex since it returns results in an array passed as an argument. The wrapper wsModes appears below:

Function wsModes(x As range) As String
    Dim n As Integer
    Dim p() As Single

    Dim res() As Single
    Dim resString() As String
    Dim rescount As Integer

    p = Range2Array(x, n)

    ReDim res(1 To n)

    rescount = mode(p(1), n, res(1))

    If (rescount = 0) Then
        wsModes = "None"
    Else
        ReDim resString(1 To rescount)
        For i = 1 To rescount
            resString(i) = Str(res(i))
        Next i

        wsModes = Join(resString, ", ")
    End If

End Function

In wsModes we need to define a results array to pass to our Fortran function. If the Fortran mode function returns a result of zero modes, this function will actually populate a cell with the string «None.» If valid modes are returned, a text list of modes is created to populate a single cell.

Our three worksheet functions, wsMean, wsMedian, and wsModes, are now all callable directly from an Excel cell:

The resulting spreadsheet can now indirectly call our Fortran procedures, passing data from spreadsheet cells and properly populating resulting cells.

For time-consuming calculations, this exposure of Fortran procedures to the worksheet itself might be a poor choice because Excel often recomputes sheets when values change. The user might be better off inserting a button that triggers calls to Excel in those cases to limit the amount of computing necessary to refresh any given worksheet.

A macro-enabled spreadsheet along with the original Fortran DLL code is attached below:

• averaging.f
• averages.xlsm

The VBA code in the Excel spreadsheet will need to be updated with the proper path to the Fortran DLL since it currently refers to a specific, absolute path on our demonstration system. Once updated, though, Excel should be able to interface with a Fortran DLL quite easily.