Excel 2013: Macro Version Control Strategy - excel

We are using TFS as source control system and I would like to implement the following:
We have Excel files on multiple workstations (all connected to TFS) that shall always use the latest version of a macro.
Therefore, I thought about somehow defining the macro in an external file which is under source control and can be centrally maintained and mapped to the local workspace of the workstations where the Excel files are located.
Within the VBA section of the Excel files, there should only be a link to that file so that always the latest version of the macro is used (assuming that the user made a GetLatest operation on the external file containing the macro).
Is a scenario like this technically possible? If yes, how can I define that the Excel file has to import the macro from the external file?

If I understand you correctly referring to the macro containing file as an Addin should do the job.

Related

Alteryx download & process multi-tabbed excel

I am using an Alteryx workflow to download a .xlsx with multiple tabs from an FTP. The file is downloaded to temp folder as that's the option I choose. I want to further process this file by accessing various tabs. I am aware of how to process excel with multiple tabs (reading the sheet names and selecting one as template).
However, in this case, I can't select a single tab as template since the file downloaded from FTP is only created at run time. I can provide a relative path for file %temp%test.xlsx but can't access individual tabs to select one.
I need to schedule this workflow in Alteryx gallery so I don't want to use an absolute download path on local system that may fail when running in gallery.
Can someone throw light on how to get around this situation?
You can use an example of that file to develop the workflow and then change the path to %temp%test.xlsx||| with '' being one of the sheets you use.
I haven't got the exact example to test, but that should work. You may need a Block until Done before the Dynamic Input though.

How to call macros using azure api

I have an excel file containing around 100K rows in onedrive. This file contains some macros. I want to run these macros using api.I want to pass these macro functions as parameters.
For example
https://graph.microsoft.com/beta/me/drive/root:/book1.xlsx:/workbook/tables/{id|name}
Here, I want to call macros function in place tables/{id|name}
Any way to do this?
Thanks
To be able to run an Excel macro, you need a running Excel instance that opens the file containing the macro and runs the code. There is no way around this I'm afraid.
So you need a machine - physical or virtual - where Excel is installed. Then you can have a script open the Excel file there and run the macros.
If you are working in a cloud environment or on a web server for example, you would be better off rewriting the code in another language, independent of Excel. (Trust me, I've been there, done that.)

VSTO Excel Add-In and SpreadsheetGear

We're working on a Excel Add-In in C# .Net 4.
One of the requirements is to update a worksheet with results of some processing.
The issue is, we need to do this both while the Excel file is open (with the Add-In), and also in batch (while the file is closed).
We have a SpreadsheetGear licence already to generate Excel files.
Is it possible to modify an XLS file whilst it is open in Excel, using SpreadsheetGear?
Or must we have two sets of code to generate the same information? One using Excel Interop for open files, and one using SpreadsheetGear on closed files?
Got a direct response from SpreadsheetGear.
SpreadsheetGear runs on a totally separate process from Excel and has
no way to access their runtime and/or currently opened workbooks—our
product was built from the ground up using the .NET Framework
libraries and has absolutely no dependencies from Excel. The only way
to access files like you require would be to first save them to disk
from Excel and then open them with SpreadsheetGear.
So it looks as if we'll have to implement two sets of code to do the same thing.

Is this possible in Excel: Open XLS via commandline, OnLoad import CSV data, Print as PDF, Close Doc?

Thinking that to solve a problem I've got this is the fastest solution:
Generate a custom CSV file on the file (this is already done via Perl).
Have a XLS document opened via commandline via a scripting language (clients already got a few Perl scripts running in this pipeline.)
Write VBA or record a macro that executes the following OnLoad:
Imports a the data from the CSV file into the report template,
Print the file via PDF driver to fixed location using data in the CSV to name the file.
Closes the XLS file.
So, is this possible via Excel macros, if not is it possible via VBA -- thanks!
NOTE: Appears I've got to have a copy of MS Office anyway, so this is much faster to get going than using Visual Studio Tools for Office (VSTO). The report template is going to be on a server, and this way the end user can build as many reports as they like, "test" by printing a PDF using a demo CSV file, and import/embed the marco or VBA when they're done. I'd looked in Jasper Reports, but the end user is putting ad-hoc static text and groupings all over the report and I figure this way they can build reports how ever they want and then automate them. Both of these questions by me and the resulting comments/feedback are related to this question:
In Excel, is it possible to automate reading of CSV data into a template and printing it to PDF from the commandline?
Is it possible to deploy a VB application made in Excel as a stand alone app?
FOCUS OF QUESTION: Again, focus of the question is if this is possible via Excel marcos, if not macros VBA, and if there's any huge issue with this approach; for example, I know this is going to be "slow" since Excel would be loaded per job, but there's 16GB of ram on the server and it's not used at all. Figure since I've got to have a copy of office on the server anyway, this is a much faster approach.
If you've got any questions, let me know via comments.
I suppose you could launch the report file from perl and then have a macro inside the report file automatically look for the newest csv file to import. Then you could process and output. So you just need to launch the proper excel file with the embedded macros from perl and then let excel and VBA take over.

an HTML file is NOT an Excel file, right?

we use an application that has an "export to excel" feature that doesn't work on PC's that done have outlook express installed.
i know, you're thinking "WTF does outlook express have to do with excel files?"
i asked the same thing, and here's what i found:
the file being generated is actually one of those Microsoft Single File Web Pages (.mht) and NOT an excel file
you need to have outlook express installed to actually view a .mht file.
i've explained to their support people that just because you can slap a .xls on a file and excel will open it does not mean its an excel file, and does not mean that this is the right way to do it.
how would you explain that this is not proper?
Many people (especially managers) confuse Excel files with reporting files. In my opinion, a file is only qualified as an Excel file if it meets all of these conditions:
Is a spreadsheet formatted in one of the many Microsoft Excel formats.
Can be opened in the most recent version of Microsoft Excel.
Is editable in Microsoft Excel.
In your case, I'm guessing only condition #3 is met, so it's no Excel file. But your support people may still call it a reporting file.
If a clean Windows image with only Excel installed can't open it, then it isn't in Excel format. Period.
If a Windows machine with Outlook Express, but without Excel can open it (if you change the extension) then it can't be an Excel file. I'd combine that with Ignacio's suggestion for a slam-dunk.
Plus, surely if it's MHT, then you can't actually do spreadsheet operations on it? Or am I misunderstanding how it works?
I don't think your statements are correct. Excel (2007) has import and export filters for single-file HTML documents (.mht) even if there is no Outlook Express installed. However, this is not a native format and worksheet features such as formulas cannot be retained (see http://office.microsoft.com/en-us/excel/HP100141051033.aspx#7)
So what you should make clear to your customers is that there is a difference between an applications native file format and a format which isn't designed to contain spreadsheet functionality and that is only supported via an import/export filter.

Resources