I have an application that is written in Excel VBA, myApp.xls. Currently we use InstallShield to distribute the application. Since we are moving to Windows Vista, I need to be able to install the application as a standard user. This does not allow for me to update the registry during the install process. In addition to the excel application we also have several VB6 applications. In order to install those applications, I was able to use RegFree com and Make My Manifest (MMM) as suggested by people on this forum (I greatly appreciate the insight btw!). This process, although a bit tedious, worked well. I then packaged the output from MMM in a VS '05 installer project and removed the UAC prompt on the msi using msiinfo.exe. Now I am faced with installing an application that basically lives in an Excel file. I modified a manifest that MMM created for me for one of my VB6 apps and tried to run the excel file through that, but I did not have much luck. Does anybody know of a way to do this? Does RegFree com work with VBA? Any thoughts or suggestions would be much appreciated.
Thanks,
Steve
Yes, it is possible to use registration-free COM through VBA, on Win2k3+.
Fundamentally, reg-free says "this COM class no longer needs to be registered to be discoverable, instead registration info will be carried by a manifest".
Manifests themselves are implictly referenced by executables when they are embedded in the executable, or named *.exe.manifest.
However, in the case of VBA -- your code doesn't live in an executable you control, so you need another way to get a reference to the manifest.
That's where the Microsoft.Windows.ActCtx object comes in - it specifically allows you to instantiate your object given an explicit manifest reference.
For example (in JS, since I'm rusty on VBA syntax):
var actCtx = WScript.CreateObject("Microsoft.Windows.ActCtx");
actCtx.Manifest = "myregfree.manifest";
var obj = actCtx.CreateObject("MyObj");
Related
Is there a way of storing VBA source code that's common and accessible to all Microsoft Office products..? I have a variety of functions which I use in both Access and Excel, and sometimes even Word. I modify and add to the the functions and modules frequently. The copying, pasting, and maintaining of code between projects can get tedious, and I inevitably overlook something.
I know I could do something like write a class/ocx/addin in VB6 or DotNet, compile it, and reference it in my VBA projects, but I was hoping for something more simple.
If there was a way to store VBA code in independent files, and open them with the VBA IDE in a standalone mode of some sort, that would be outstanding, but I know the IDE doesn't work that way...as far as I know.
I know I could do something like write a class/ocx/addin in VB6 or DotNet, compile it, and reference it in my VBA projects, but I was hoping for something more simple.
Unfortunately that's your best bet.
As you know VBA code is hosted, wrapped-up in a host document: a VBA add-in is still tied to its host document (.xlam, etc.), and as such can't be shared with another host.
In VBA-land what's meant to be shared between VBA projects, is type libraries - things you compile separately from the VBA project, and reference from as many projects as you like.
If you have a VB6 IDE, you can compile a 32-bit DLL that VBA projects can reference. The problem is that it won't work with 64-bit hosts - the solution is a .NET type library, written in the .NET language of your choice, made COM-visible. Note that COM-compatibility does restrict what you can expose in your API: for example you can't expose generics, and method overloads will look weird.
If a type library isn't an avenue you wish to explore, then your choices are rather limited, and IMO sub-optimal.
IMO the only thing that can "work" is a bunch of exported code files in some common folder, and the VBA projects that need to use that code need to literally import these code files. The risk here being, that if you make any changes, other VBA projects using an unmodified version of that code will not "see" these changes, IOW by doing that you're multiplying the number of times you need to fix a bug by the number of projects using that code.
Or you could have some code that uses the VBIDE extensibility type library to ensure the set of imported modules always match exactly with the exported files in that common location.
If you want to use VBA in the same Office program (e.g. one Excel file to another, or one Access file to another), you don't need to use any special kind of file. You can add a reference to an external database or worksheet with macro's enabled.
Navigate Tools - References - Browse - Excel/Access file - Add the file
See the following screenshot:
You can't use files across different Office applications this way, but you shouldn't. Each application has different built-in functions, so your code is likely incompatible anyway.
I have a SAP Business Objects Web 7.5 Add-in in Excel 2007.
The add in itself is made up of a compiled .xll file (CtExcelLinksWeb.xll) and a number of dll's.
A bit of vba shows the xll is registered, and all of its registered functions.
However, when I try to use one of these functions in VBA using Application.Run(), I get
Runtime 1004 - Macro may not be available or may be disabled.
I have tried registering the xll within the same sub (Application.RegisterXLL ()) and upon registering a VBAProject called CtEmpty.csv is created
I want to be able to automate the use of this add-in using VBA as it does long winded repetitive tasks, and then I can work on figuring out how to use the functions
Any help will be appreciated
Are the DLLs on the PATH? It may be that Excel can't load the DLLs that the XLL is dependent upon. Dependency Walker (depends.exe) is a handy tool for troubleshooting this kind of issue.
Also, have you tried using File/Options/Addins to register the XLL, as well as VBA code?
I want to find the way to read excel file in Metro app (use C#/XAML) but probably there is no solution. Anyone know if there is any reference support to do this (like Microsoft.Office.Interop.Excel in Win32)? Help me.
If you want it free, write your own ExcelReader, I've shared some idea here:
Reading Excel file using C# in WinRT platform
If you don't mind paying, you can try either ComponentOne or Syncfusion, they've got out of the box of manipulating (reading and writing) office documents.
There's paid control available from ComponentOne.
I made a discovery some time back. Just follow these steps:
Create a .doc/.xls/.ppt file in office 2003. Keep some test data in there and close the file. Now rename the file to change it's file extension to a random string, taking care that it is unassociated, like test.asdfghjkl etc.
Double click the file and it opens seamlessly in the parent application.
Now AFAIK, windows checks the file extension of the file and uses it to do an action, viz open an application and pass the file to it to open. Then how does the office suite manage to do this?
EDIT: How about the case when the extension is changed to one that is associated with another application. Is there a priority algorithm in place for handling that ?
Do you have the "View extensions for known types" option on?
EDIT: #Comments....
Yes, its a stupid/insulting question, but when troubleshooting a problem I have learned to assume nothing, and trust the users 0%.
BUT, I tried it, and you're right. Its stupid that MS has this kind of behavior, and it can only lead to security vulnerabilities, which led me on a search for your answer.
From the posts at http://seclists.org/fulldisclosure/2007/Jan/0444.html
"You have stumbled on an age-old
quirky behavior of Windows. Office
document formats are based on a
standard Windows container format, OLE
structured storage files, also known
as "docfiles". A docfile's name and
extension are irrelevant - the file
is, conceptually, a serialization of
an OLE object, and like all
serialization formats it contains the
identifier of the application that
produced it, in the form of an OLE
class id (in GUID format) in this
case. You can easily verify that it
doesn't work with the newer Office XML
formats"
Indeed it doesnt work for the 2007 *X file types, but 2K3 is still a problem. To solve this problem... Upgrade! =)
And here at security focus under TOC point 2.
So, there you go.
I can't seem to make this happen now, but I know I saw Windows reading XML processing instructions a few years back. Maybe that is what's going on?
I am stuck with a problem
The Requirement is that, there a complex Excel file(XLS) that is used as template; it has Macros and all the worksheets are either locked or hidden. When the user clicks to download it, the follows operation occurs
Unlock a particular worksheet, fill some data # certain cells and then lock it back.
Unhide a worksheet, fill some data # certain cells and then hide it back.
I think there are two options to resolve it (if there are more then please let me know)
Interop libraries / Excel Object Library
OLEDb Driver
I cannot got with the option 1 as excel is not installed on the webserver and I heard that it's not a good option to install MSOffice # webserver.
My question is that can we use OLDb to perform the operations mentioned above OR is there any other option ???
BTW Sharepoint service is also not available :(
Please help!!!!
You could maybe try ExcelPackge.
See this article:
Server-Side Creation of Excel 2007 Files Using .NET 3.0 and Office Open XML
see also:
Office Space - Building Office Open XML Files
Check out this question I asked some time ago for an overview of options. I ended up going with the Aspose library, which I link to in my original post. It's not cheap, but it does the job very simply and elegantly. It even has templating functionality built in (called SmartMarkers, IIRC).
SpreadsheetGear for .NET will handle this and has an API which is very similar to Excel. You can see what our customers say and download the free, fully functional evalution here.