I am woking on a google script, which is performing some thermodynamic calculations. The script is linked to a google spreadsheet for reading input data and for writing results as well.
An issue is that in the script I need to determine some water steam properties in order to perform the calculations. However, such properties are not constant and they have to be determined by calling a DLL containing water steam properties functions.
Is there any approach how to call a function from an external (a user's) DLL in a google script?
Since a source code of the DLL for Matlab and VBA (from an Excel's macro) is available, another (but significantly more arduous) option is to rewrite the code into javascript, am I right?
Related
Is it possible to have modules be external to the actual Excel file and call the functions/subs within them externally?
My thinking is if there are multiple Excel files that use the same module, instead of updating each one of those files separately when I make a change, can I just update the one module stored on a server or something?
I have doing something like you describe for years. You can move your VBA code to a VB6 ActiveX dll, organize it into classes, and load that dll as a reference from Excel VBA.
This is a good way to reuse non-workbook specific code. For instance, I have code that queries a mainframe. I like to call it from Excel, but the details of the connection and how data is passed are contained in a dll that I can load from Excel, VB6, Word, .NET, wherever. I have a similar dll for reading data from AutoCAD drawings, one for interfacing with a product DB on a MySQL server, etc.
The code that remains in Excel tends to be simple formatting stuff. Say I return a variant array of strings (technically a COM SAFEARRAY) from some library that I wrote. I would then output it into Excel, maybe do a text-to-columns, and have a list of results returned to the user.
You can also pass and return more complex data structures. The beauty of VB6/COM Automation (and I didn't appreciate this until I learned to do it the harder way in VB.NET or C#) is that the data will flow in and out of your components seamlessly and all the necessary interfaces will be created for you.
The main change to your code will be replacing things like ThisWorkbook or ActiveSheet with explicit parameters like (Byval sht as Excel.Worksheet). These will be caught at compile time in VB6 (since it doesn't know what ThisWorkbook is), so you cannot overlook them; you are forced to pass an explicit reference.
I also notice that my code inside the dll becomes more paranoid if it receives a Worksheet or other Excel object as a parameter. In VBA you might have had more assurance that you were passing a good object since it was private to a given workbook. The dll does not know who is calling it, so I view the passed-in object with more suspicion (check if Nothing, sheet name, formatting clues to ensure I am using what I think I am using).
The only downside I see is that you will have to get a copy of Visual Basic 6.0. I bought mine in 1998. It is no longer available from Microsoft, but surely there is someone out there who will sell it to you. The latest service pack is SP6.
You will also have to become familiar with "regsvr32" and "regsvr32 /u" to deal with the "ActiveX can't create component" errors as you open your workbooks on various computers. I just publish my dlls to a mapped network drive and re-register them on the user's computers whenever there is a significant change. Obviously this is a intranet/single company solution. Publishing the updated versions is much more of a pain the farther you are distributed.
Not sure if this would satisfy your needs, but you could create your common module as an "add-in" and so install it so that all files that you open in the same instance of excel would have access to the add-in code.
It would not be my recommended way of doing it because I would be worried about suitable testing of all the excel files that use it, when you make a change, plus the added complexity of getting users to install your add-in (this may not be an issue for you). I have a "developersToolkit" module I use across 8 different Workbooks, but I import the module into each workbook so its stand alone and I can also test changes for compatibility with each of the 8 workbooks.
Trying to do this:
let excel = AutomationFactory.CreateObject "Excel.Application"
excel?Visible <- true
excel?workbooks?Add ()
Although EXCEL.EXE does appear in the Task Manager when I run that code, the excel object apparently has no properties, which makes the rest of the code pretty tough to execute. (If I place let allProps = excel.GetType().GetProperties(BindingFlags.Public ||| BindingFlags.NonPublic) after the first line, it evaluates to an empty PropertyInfo array.)
In examples of Silverlight/Excel interop that I've seen, everyone simply does what I'm trying to do, with no problems. Not sure why I'm having this issue...??
AutomationFactory.CreateObject creates an automation server, which is intended to be used via dynamic dispatch. http://msdn.microsoft.com/en-us/library/ff457794(v=vs.95).aspx. To me, this makes sense, since the properties available would be defined by the object being automated.
Using object.GetType().GetProperties() will only give you pre-compiled properties of the object, not the dynamic properties.
If you are automating excel to create a spreadsheet, you may have an easier time using a third party library that does not use Excel automation. Many of them are listed in this answer: Create Excel (.XLS and .XLSX) file from C#
I am trying to load a dll (it's not my dll) and it's written in C++
There are no exports to my knowledge, but it does what I need it to do once loaded.
assert(package.loadlib(dllfile,'')()
This throws an error, obv, "procedure not found" but the dll is still loaded, and works as intended.
if I call the above function a 2nd time, it crashes the client, so I need a checker of some sort.
my question is, is there a way to verify it's loaded?
In Lua 5.1 when using package.loadlib as the second argument you must specify the name of a function actually exported by the DLL. It is not important which, if you only need to force the Windows dynamic linker to load the DLL (that seems your case).
To discover such names you can use DependencyWalker (free tool). Open the DLL using depend.exe and look at the export function list panel (the first column has an E header label). Choose any function and use its name as the second argument (If it really doesn't have exported functions you are out of luck!). Try to choose a function labeled as C (not C++). C++ exported functions have mangled names that could cause problems.
For example, say you want to load kernel32.dll: using depend.exe you can discover that among all the exported functions there is one named AddAtomA (but any other C function would do). So you could use package.loadlib in this way:
assert( package.loadlib( "kernel32.dll", "AddAtomA" ) )
The assert call ensures that if the DLL cannot be loaded an error is issued.
To verify a DLL is actually loaded you can use ProcessExplorer (another free tool).
Make sure your script is running (you can put an io.read() statement in a suitable place to keep your script from terminating),
then open ProcessExplorer window,
select the process relative to your script (probably some lua.exe, but you can drag the "target" tool on ProcessExplorer toolbar to your script window to discover it)
and type ctrl-D.
A lower panel should appear showing all the DLLs that the selected process is using. Browse the list to see if your DLL is listed.
Hope this helps.
What is the best way to avoid duplicating code when working in VBA?
I'm used to languages where I can just add an import statement and get access to all a class's public properties and functions, so I can just create a utility class with some common functions and have access to that in any project I choose to import it to. Any time I want to update one of those functions, one edit is all it takes to get it working across all projects.
Is there any good way to replicate this functionality in VBA?
What follows focuses on Excel but I am pretty sure the same would apply to any Office products.
The easy way is to save your reusable code as an addin (*.xla for Excel 2003, *.xlam for Excel 2007+). You then add the addin to Excel and all the spreadsheets you open will have access to the custom functions you have in your addin. If you add specific VBA code to a spreadsheet, you can add a reference to your addin and your VBA code will have access to all the public sub, function and classes of your addin.
In my organisation, we use 3 home made addins - they are stored in C:\Program Files\OrganisationName. And everybody has access to them. When an update is made, we only need to copy the new version to everybody's hard drive and restart Excel and they have the new version.
The addins contain utilities functions such as functions to:
read data from / write data to spreadsheets / files / databases.
usual data manipulation such as removing duplicates from a list
advanced statistical functions
etc.
A few drawbacks:
If you have several instances of Excel open, only one can update the addin, the other instances are in read-only mode
If Excel crashes, the auto recovery mode generally does not save the changes you made on your addin (TBC on newer versions) - there are a few tools to auto save regularly
An alternative is to develop xlls or COM libraries in VB or C# for example, but this is something I have not tried.
There are plenty of tutorials online if you need a more detailed procedure.
I am looking for a way I can automate an Excel VSTO Document level solution, to be called from an external application, similar to the VBA approach like "xlApp.Run("WorkBook", "MacroName") which we use to auto mate VBA solutions. As this will be a document level solution, Remoting or Webservices are not options. I am using VSTO 2010 and Framework 4 targeting Excel 2007 and 2010 versions.
Say, I have a Document Level Solution with a workbook named "TestBook" which contains a VSTO based class "MyClass" with a static function "GetData(string connection)" I am looking for a way to make a call to GetData function, from an external application. The solution itself will be loaded into excel by the external application too using Application.Workbooks.Open method.
To summarize: I am trying to find a way to get a reference to an object (ideally) and make a call to a function from a Document level solution after loading it. I am trying both ways like (External App)->(Addin)->(Document level object) but the route (External App)->(Document level Object) would be ideal.
Any pointers would be greatly appreciated.
I suspect you need to go about this a bit differently...
The call a method the way you want you might a to resort to something called a "COM Automation AddIn" and implement a UDF this way.
You can then just place the call to your method as a formula inside any sell of that workBook - Excel eveluates that formula by calling your implementation. You can even tell Excel to reevaluate it.
Another option might be to build the functionality as a so-called RTD-server which is referenced in your workbook...
For some information see these links:
http://msdn.microsoft.com/en-us/library/aa662931%28office.11%29.aspx
http://msdn.microsoft.com/en-us/library/aa140060%28office.10%29.aspx
http://weblogs.asp.net/kennykerr/archive/2008/11/13/Rtd3.aspx
http://msdn.microsoft.com/en-us/library/aa140059%28v=office.10%29.aspx
http://msdn.microsoft.com/de-de/library/microsoft.office.interop.excel.rtd%28v=office.11%29.aspx
http://exceldna.codeplex.com/workitem/5902 (free library to ease the development)
http://www.add-in-express.com/docs/net-excel-automation-addins.php and http://www.add-in-express.com/docs/net-excel-rtd-servers.php (commercial library to ease the development)