Does anyone know of good reference material for creating a com addin for the VBA Editor enviroment, i know its exactly the same as writing a com addin for common enviroments using the addin model provided by microsoft using the IDTExtensibility2 interface. just registering the com registry keys to a different location, Where is that location?
Also any examples on .net interop code for how to reference the code editor, in as much detail as possible, add custom menu items to the context menu. you know normal customization code. Also if anyone knows how to hook up visual studio for debugging said project. If you know of anyone of these, id be very much indebted.
It looks like the person who put together the MZ Tools has a small section on their site with some resources on building VBE Addins
http://www.mztools.com/resources_vs60_addins.aspx
This could be the registry location - HKCU\Software\Microsoft\VBA\VBE\6.0\Addins
I found this by running Process Monitor from sysinternals.
Capture Events using Process Monitor
Ran Excel, Alt+F11, Tools -> Addins
EDIT: I don't know much about .net interoping with addin code.
But, I would open the addin project, set the necessary breakpoints, keep it in run mode, open the VBA editor, load the addin & take actions which will make me break into the code of the addin.
"Microsoft Office 2000 Visual Basic Programmer's Handbook" (ISBN 3-86063-289-2) has four (!) pages on this subject. I only have the German edition, but I could translate the important bits if you think it might help. Obviously, nothing about .Net Interop in there, but some basic info about writing VBE Add-ins.
Check out O'Reilly's Developing Visual Basic Add-ins: The VB IDE Extensibility Model
The book, while an excellent resource, is mostly based on the normal VB Editor -- but combined with digging through the Object Browser, and references like those # MzTools (as Jon pointed out), you should be good to go.
I used both of these resources when dealing with the VBA IDEin EMC-Captiva's InputAccel and FormWare environments, which only expose portions of the VBA IDE.
Related
I am interested in creating a custom VSTO Excel Addin to provide customized classes for VBA in Excel. This link provides a walkthrough for this task, however there is one question left for me: How to provide intellisense support for VBA for this customized routines.
The IntelliSense technology available in VBA is based on the COM technology. So, if you try using the late-binding technology with any Office application automated you will not find the IntelliSense for such objects as well. Only early-binding technology allows using this technology and get intellisense available to developers. You need to create a COM interface which could be implemented on both sides. After adding a COM reference to that library you may get hints like intellisense.
Out of the box VSTO doesn't provide anything for getting the IntelliSense available in VBA.
I have written two addins , 1 for excel and 1 for word. However these addins have a lot of duplicates: Database handling, file handling,array handling which I would like to update 1 place instead of two.
We do have access to sharepoint, and could get access to visual studio. The thing is that people like to use file explorer and find the correct word or excel file, then open it then press a button inside the application which then should do things with the active document.
This is why we haven't written it as a .Net application yet, because that requires that people browse for the file inside the .NET application uless I am mistaken.
Is it possible to make an Addin which works both excel and word, or a dll? AnAnother important thing is that it should be easy to roll out a new version to the user, like stored on a network drive or similar.
Yes it is possible
The Hard Way
You can create a .Net DLL and call it from VBA. In visual studio a lot of people use Unmannaged Exports by Robert Giesecke to create DLLs that don't need to be registered (that way the DLL can be shipped with your document, and as long as it can be found you can use it).
Alternatively you might be able to do it manually as shown here by Hans Passant.
The Easy Way
Once the DLL is created you can declare it in a VBA module the same way you declare any other DLL for Late Binding and then call it from your code.
OR if you're happy to create the DLL and add it as a reference (possibly less portable) you can make it COM visible and register it for COM Interop in Visual Studio; this is probably the easiest way to go because you can then use Early Binding.
This is a walk through that might help: http://www.geeksengine.com/article/create-dll.html
But if you want to store the DLL on a network drive, well it might be that you really want to look at doing it the 'hard way', in which case look here: https://stackoverflow.com/a/5934745/3451115 and here: https://msdn.microsoft.com/en-us/library/bb687915.aspx
I apologize if this issue has already been explained but I have searched and not found an answer that I can comprehend. I have been using VB.Net for years to automate CATIA by adding their libraries and calling the exposed methods, properties, etc. I wrote some some basic code to C#.Net and was disappointed to find that the objects are not exposed in the same way as they are in VB. What I mean is when an object is examined in the debugger or watch window, the properties are not displayed in C#, but they are displayed in VB. This makes it pretty much impossible for me to debug CATIA automation in C#, which doesn't seem right. Something must be missing. I have added the COM libraries to the project and have Included them in the header properly. The intellisense is working and the basic methods of the CATIA objects are visible in the watch/debug but not all methods and properties are visible and I can't interrogate them by manually typing a object.get_Name() or something like that in the debug window.
I've attached images of two watch window results for identical code. The first is from VB.Net and you can see how much more information is available. The second is from C#.Net and you can see how little information is available. How can I access the same level of information in the C# debugger that I see in the VB debugger for COM interop assemblies? One thing I noticed that may be a clue here is that in VB, there are many object properties which appeared as get_ methods in C#. For example, the property Document.Name in VB is found as Document.get_Name() in C#.
OK, so the site won't allow me to post images since I "need at least 10 reputation points." Hopefully there's enough problem description to go on.
I was wondering if there was a way to set up communication between an instance of excel and a C# Application. For instance, when a cell value changes, I would like to send the updated value to the C# Application in real time.
Thanks in advance!
You need the Office Primary Interop Assemblies, which are a .Net wrapper for the COM API exposed by MS Office. You can consume events through these, so you might be able to set up a listener that will capture the event that you want.
You can use the Visual Studio Tools for Office (VSTO) project types available in Visual Studio to automate Office from C# code. This ensures you use only managed code and do not rely on COM or the Primary Interop Assemblies being available/installed.
This is the preferred approach when compared to the COM solution. For further information and examples, please take a look at the MSDN page.
I am writing a C# program in Microsoft Visual Studio 2010 that stores some information inside of the local user settings like so:
Properties.Settings.Default.userActive.Add(connection.Active);
Properties.Settings.Default.Save();
I also have a Visual C++ application that would like to read these stored user settings. Is it possible for my Visual C++ application to read the C# application's user settings?
Similarly, how would I go about accessing the local user settings directory in C++?
It seems like there is no Microsoft sanctioned way to do what I am attempting to do. In case anyone else comes across this I will briefly explain what I've decided to do. Here was a helpful guide. I am ultimately just populating an xml file from the C# and placing it within the users AppData folder located at:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
I am then using my C++ to locate it using:
TCHAR myCharArray[MAX_PATH];
SHGetFolderPath(NULL,CSIDL_LOCAL_APPDATA,(HANDLE)-1,SHGFP_TYPE_DEFAULT, myCharArray);
I then parse the XML file using C++ and read in the settings. This was a much more manual process than I would have liked, and leaves room for a lot of error unfortunately. Anyways, thanks everyone and good luck!
You can make the c# class COM callable through .NET COM Interoperability and COM callable wrappers.
Check out
http://blogs.msdn.com/b/deeptanshuv/archive/2005/06/26/432870.aspx