AutoShape.Adjustments object - 2003 vs. 2010 or VBA vs. VSTO? - c#

I am porting some PowerPoint VBA macros into C# inside a VSTO add-on which automate certain tasks.
The macros were written for PP 2003 and I'm writing the VSTO add-on with PP 2010 as a target. The macros make heavy use of AutoShape-manipulation through the AutoShape.Adjustments object.
In VBA under 2003 i would access the X-Axis position of the "line-target" of a Legend-with-Line autoshape like this:
shape.Adjustments.Item(1) = someFloat
In c#/VSTO this seems to have changed to
shape.Adjustments[6] = someFloat;
There is now .Item collection in c#/VSTO.
Does anyone know where these values are documented, and most importantly, where they are documented for 2010?
Or is this all caused by switching to VSTO? If so, why would they choose to have you use different index numbers?
For now i'm stuck to manually test every Adjustments index in C# one after the other until i find the one that corresponds to the target in VBA.

I've never run across any documentation that explains what the various adjustments do and which shapes they apply to.
As to the difference in indexing/syntax, a wild guess:
In VBA, Shape.Adjustments.Item(x) and Shape.Adjustments(x) are equivalent; the default property for Adjustments (as with most collections) is .Item, so it's not strictly necessary to explicitly use it.
Perhaps in .NET, you index into all of the Adjustments properties, since (as I understand it) there's no longer a default/implicit property. In other words, perhaps what you're seeing is an offset that will be consistent for all shapes.

Related

Share code between office applications

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

How to Access the Undo Stack in Excel from C# via Office Interop?

I'm building a C# app that needs to interact with an Excel spreadsheet via Office Interop. I'd like to gain access to the full Undo stack so I can make a series of changes to the worksheet and then roll them back one at a time if necessary. I see that the Word Document object in the Interop assemblies has UndoRecord and some other niceties, including an Undo function. For example, I can call Microsoft.Office.Interop.Word._Document.Undo() with a parameter to undo multiple actions. Excel's Undo stuff, on the other hand, looks much more limited. Sure, there's Microsoft.Office.Interop.Excel._Application.Undo(), but it goes only one action deep, and if called again performs a "Redo" instead of going deeper down the stack.
I've found code online where VBA developers coded their own Undo histories for Excel because that was the only way to get the desired functionality. I don't see anything like this for C#, though. Is there any way to mimic the way Word's Interop undo works in Excel?
Alas, what's true for Word isn't for Excel. Probably because so many more people write Word VBA :). See this John Walkenbach page for what is possible in Excel VBA (and interop). Here's part of his description:
Making the effects of your subroutines undoable isn't automatic. Your
subroutine will need to store the previous state so it can be restored
if the user choose the Edit Undo command. How you do this will vary,
depending on what the subroutine does. In extreme cases, you might
need to save an entire worksheet. If your subroutine modifies a range,
for example, you need only save the contents of that range.
EDIT:
There is the Application.Undo method, but it's very limited. Here's the description from Excel 2010 VBA help:
Application.Undo Method
Cancels the last user-interface action.
Remarks This method undoes only the last action taken by the user
before running the macro, and it must be the first line in the macro.
It cannot be used to undo Visual Basic commands.
In regards specifically to Interop, I'm sure there's nothing available that's not in VBA itself.

Integrating C# code in Excel

I have an Excel file with many different, but very similar, userforms.
When I click on a cell in my worksheet a specific userform will open according to the cell text.
I wanted to know if there is a way to add a C# form to Excel which will behave as a userform? Since the visual studio interface is much simpler and a lot more generic than VB.
I know you can create C# add-in's for excel, but these are used to add buttons, ribbons, etc.
what I need is a way to add a dll which will be activated when clicking on a cell, this dll must be easy to update, and it should not include installation (like the add-in's).
I got the following answer from a different forum:
You have some possibilities
1) Actually Excel (and practically all Office application) support Add-ins. Thus you could make a legacy excel add-in. There are several tutorials out there, but this is not the simplest one.
2) An other interesting approach exceldna.codeplex.com/[^]
3) You can call managed code from excel vba, but it is not the wisest one, since vba runs in a rather undeterministic way. Start here: richnewman.wordpress.com/2007/04/15/…^]
4) Interop Forms Toolkit[^] might be also an alternative – user2134909 2 mins ago edit
I haven't thoroughly examined them, but they seem promising

Excel 2010 equation editor access via C#(VSTO)/ VBA

I need to get access to Equation Editor that's built in Excel 2010. In Word2010 it's quite simple as it provides OMath interface to access it via C# or VBA. There's no such thing in Excel eventhough it's possible to insert equations this way. Has anyone solved this problem ?
I need to extract the equation from the eqution object in a text way (no metter if it's Latex, MATHML or any other language. It just has to be a single string)
Of course I can use MathType to do this (Actually I've alredy done this with MathType) but I don't want to force the User to buy MathType as Excel has built in feature that would do the trick.
Have you tried adding an OLE object first, as mentioned in this link?
http://www.techyv.com/questions/it-possible-equation-editor-vba-excel-2010
I don't have an enormous amount of experience with Excel's equation behaviour but it seems Excel doesn't use the OMath object. As far as I understand:
You can add a new Equation with:
ActiveSheet.OLEObjects.Add(ClassType:="Equation.3", Link:=False, DisplayAsIcon:=False)
And subsequently, you can access these objects using the OLEObjects collection:
ActiveSheet.OLEObjects.Item(1)

vba Extentiblity, com addin guidance?

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.

Categories

Resources