I want to show a waiting dialog, in the meantime all the calculations concerning with PowerPoint objects still are running in the background. My purpose is during the time dealing with PowerPoint objects, I try to prevent the user from interfering with the UI.
It seems that there is no way to deal with PowerPoint objects in the background. Is there any workaround for my case?
Thanks
Note: I am using VS Ultimate 2013, C#, PowerPoint 2013, vsto
Office applications use the single threaded apartment model. That's why you need to use the main thread for working with Office/PowerPoint objects. However, you can extract the required information into .Net collections and process the data on another thread.
But if you need to work with PowerPoint objects, a possible solution is to display a non-dialog form with a progress bar which display the state of your actions. Thus, end users will not be able to access the UI of PowerPoint. Don't forget to specify the parent window handle (PowerPoint window handle) for the Show method (see the IWin32Window interface).
Related
everyone,
I am new to VBA and would like to know if it is possible to execute a menu button from a WordAddIn.
In the picture you can see which button I would like to execute using VBA.
Unfortunately, I can't record it via macro.
The Word object model allows executing built-in ribbon controls using the CommandBars.ExecuteMso method which executes the control identified by the idMso parameter. This method is useful in cases where there is no object model for a particular command. Works on controls that are built-in buttons, toggleButtons, and splitButtons.
But in your case the control comes from a third-party add-in which doesn't expose IDs and the CommandBars.ExecuteMso method can't find it and invoke the command programmatically.
To get the job done you may consider using the Microsoft Active Accessibility which is a Component Object Model (COM)-based technology that improves the way accessibility aids work with applications running on Microsoft Windows. It provides dynamic-link libraries that are incorporated into the operating system as well as a COM interface and API elements that provide reliable methods for exposing information about UI elements.
Also you may contact the add-in vendor for providing public methods that can be called from your solution. That's also a possible workaround instead of calling UI elements on the ribbon.
I'm trying to understand some of the behaviors I'm experiencing in my custom outlook VSTO ribbon and the main difficulties I'm facing are tied to what seems to be a single instance of the ribbon being shared among concurrently open inspector windows (my custom ribbon is displayed for ribbon type "Microsoft.Outlook.Mail.Compose"). Is there indeed a single instance of the ribbon being shared among potentially multiple instances of inspect windows? If so, how do you handle concurrent different states in the different inspector windows?
What you do is create the one custom Ribbon and from each view you handle the items in the Ribbon that you need. Here is a question that somewhat relates to your question:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/57dc20bb-9d29-4d3e-84d2-c64de0af0244/iribbonextensibilitygetcustomui?forum=vsto
In your case you want to maintain state, that is using the same paradigm. Whenever you get focus on the composing mail you make sure the state of the Ribbon matches the state of the composing mail.
By doing so the one time loading of the Ribbon XML is no longer an issue as you have all items in one Ribbon and are able to manipulate the state for each of the composed mails.
I'm developing a Word AddIn, and I've run into a bit of a problem.
I need to modify the BuiltIn BuildingBlocks, and to do that, I need an active document.
Since Word 2013 no longer starts with an open document, but instead shows the "New (Latest)" screen, my AddIn creates a new temporary document, modifies the BuildingBlocks as it should, and then discards the temporary document.
The problem is that the act of opening a new document and closing it again, leaves the Word UI at the Home-tab with no active document open, instead of on the "New" screen as it normally would.
So my question is: How do I make Word switch back to the "New" screen?
Here is the before screen, showing normal Word 2013 behaviour on startup:
Here is the after screen, showing how it ends up now, because I open/close the document at startup:
Sorry about the danish screenshots, but the principle should still be clear.
I'm using VB.Net, but C# code can be used too, since it is easily translated.
There is no way to show the Startup screen again. Instead, you may consider running a new Word instance.
Be aware, the Word object model provides the ScreenUpdating property of the Application class which you may find helpful. Here is what MSDN states:
The ScreenUpdating property controls most display changes on the monitor while a procedure is running. When screen updating is turned off, toolbars remain visible and Word still allows the procedure to display or retrieve information using status bar prompts, input boxes, dialog boxes, and message boxes. You can increase the speed of some procedures by keeping screen updating turned off. You must set the ScreenUpdating property to True when the procedure finishes or when it stops after an error.
You may also create a template file with building blocks, then attach the template on top of the new document
It will solve you problem
I am developing an excel sheet which has lots of ActiveX elements in it.
I am not using UserForm and all the data is loaded when an activeX button is pressed.
At this point a hidden excel app is created where various actions are performed.
This new app is then combined with other data etc etc.. based on what the user is doing on the front-end with the provided ActiveX controls.
My problem comes when the "project is reset", where all the objects are released from memory and everything.
If this was a user form I would have implemented "on terminate" event where I would close hidden all workbooks that I have used, basically clean after myself.
However this is not a userform and there is no way to detect when the "project is reset"(as far as I know) so the hidden excel app that I've created remain open but nothing points to it.
If I go to the task manager i see various "EXCEL.EXE" and the number of those is basically the number of times I have run the tool.
So, is there any way for me to detect when VBA is about to "stop the project" in the same was as there is "terminate" for user forms so I can delete unsused stuff and reset elements in the spreadsheet?
Thank you!
I have found that there is no corresponding event to catch this.
Best way to handle this is to create a hidden userform object which will "hold" all global variables and objects that I define. I can then implement a UserForm_Deactivate event to catch when the form is exiting and clean up after myself.
I need to update an Access VBA app with around 30 forms in it.
I have to amend a screen that seems to have been set up right at the start of the app, it uses a lot of SQL tables. Is there an way of finding my way to the start of the code?
I come from a procedural coding background and I am unused to code that doesn't have a start and an end; I also know a bit of VB, some ASP, some .Net and general computing.
When something "automagically" happens upon opening an Access database, it is almost always because
A "startup form" has been specified. (In Access_2010 that's done in File > Options > Current Database > Display Form.) ...or...
The database has a Macro named AutoExec which is automatically run when the database is opened (unless you bypass it by holding the [Shift] key down while opening).
In addition to #Gord's answer, there's a few things you need to know. I'm going to give you the quick & dirty version.
First, there's 2 types of code in Access. VBA & macros. Sometimes what's called a macro, is really VBA.
In Access, a macro is a set of instructions to do something to the database. It's very limited in what it can do. These are often used by novices who don't know how to program in VBA.
VBA is the real powerhouse behind the scenes. It can do everything a macro can do, but a whole lot more.
Access uses an Event-Driven / Object-Oriented (at least close enough for this discussion) interface. Do a Google search on those meanings. But very quickly, the listbox on a form is an object. It has properties (like width), methods (add an item), and events (click on an item).
To see the code, for macros look to to your navigation window to your left. For VBA (modules), look to the same window, or just press Alt-F11. VBA can be used standalone in a module, or behind the scenes of a form or report.
Once you get the hang of it, you'll find Access to be a handy RAD tool for small projects.
Good luck.
It appears that you already have found the form that opens when the app starts (if not, check out Gord Thompson's answer).
The first things that happen when an Access Form opens (the "start of the code", as you called it) are the Load and Open events.
If there is any code in this form that is connected to these events, then it's in the Form_Load() and Form_Open() functions in the code of the form.