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
Related
I am programming a little application (an overgrown macro really) in Visual Basic for Applications in Office 365. What it does is:
Displays one window that has a few input fields.
Once I fill out those fields with data I can press a button on the form and a summary in a nice graphical form is displayed in a second window (a second form is displayed using UserForm2.show).
The second user form can be updated with new data by typing in updated text in first form and updating the second form by pressing a button on the first form (in the form of UserForm2.TextField1.Text = UserForm1.Label1.Text.
Both forms are modeless so the user can work in Outlook whilst the forms are running.
All works fine except one caveat:
Both forms are not visible on the Windows Taskbar, in the Task Manager, but most importantly they are not visible as separate windows to teleconferencing software we are using. And this is the macro's sole purpose.
Question: Is it possible to make the entire macro (or just UserForm2) run as if it was a separate application, so it appears in the Task Bar as a separate window, and not an internal form running inside Outlook?
The idea is not to run it independently of Outlook (or Excel), but to make them visible to external programs.
I tried a few options available on the Internet, but none of them work, and honestly I do not know where to begin, or how to circumvent it if it is not possible to do directly within the available API. Can you advise?
There are several non-modal forms in ms-access open layered above each other (with a small offset). Every time my VBA program reaches a breakpoint, a stop command or an error the active form is moved to the background (at the end of the Z-order).
I searched the options for a solution for this but did not find anything.
Why is the active form moved to the back and how can I avoid this strange behavior?
I have an document in word, which has some fields to be filled, and an button to which I want to assign a macro. When that button is clicked, that same form with empty fields needs to be appended to the end of document, including the button (which can be clicked again and do the same thing).
Here is the document I have:
https://drive.google.com/file/d/0B_2kyqxMx5x4UkxfOHJhOGVPdnc/view?usp=sharing
The main problem with what you want to do is dynamically linking the button to the macro code to be executed. The most obvious type of button to use is the legacy ActiveX control in the Ribbon's Developer tab. But that requires its own procedure entry in the document's ThisDocument class module. While it's possible to add code to modules "on the fly" this involves disabling a security option.
A more straignt forward approach is to use the MacroButton field. This creates a clickable text within the document. It can display text or a graphic (so that it looks like a button) and is assigned the name of any public Sub that takes no parameters:
{ MACROBUTTON NameOfMacro Click here }
Ctrl+F9 to insert the field code brackets; Alt+F9 to toggle between field code and field result.
Graphics in Word 2010 and later:* The was a change to the graphics engine in Word 2010 which affects the behavior of graphics objects in the MacroButton field. Clicking the object triggers the Ribbon utility for working with graphics - the field code no longer "hides" the graphic. There are a number of ways you can work around this:
Use an IncludePicture field (which works with the old graphics format) to bring in an outside picture file. Once the linked picture is in the field it can be converted to a static picture by selecting the IncludePicture field and pressing Ctrl+Shift+F9. Word respects the old graphic format and the picture is click-able.
{ MacroButton NameOfMacro {IncludePicture "C:\\Path\\picture.jpg" } }
Use the old *.doc file format. Note that this will restrict some of the things that can be done with the document, but it will force use of the old graphics engine.
Instead of a MacroButton field, use the WindowBeforeDoubleClick event or WindowSelectionChange event to run the code.
*With the exception of unlinking the IncludePicture field (which I discovered myself), this information came from this discussion on the Microsoft Answers site
If you want to run the macro with a single rather than a double-click (the default) you need to run the following line of code. This applies to the entire Word application and needs to be run everytime Word restarts. You could put it in an AutoNew macro in the template / AutoOpen macro in the document:
Application.Options.ButtonFieldClicks = 1
The simplest way to store the entire content you want to insert repeatedly is as a Building Block (formerly known as AutoText).
BuildingBlocks are stored in templates. If your document is being created from a template, that would be the logical place. Another possibility would be a special template you use for this purpose. Normal.dotm can also be used but keep in mind this does sometimes get removed.
(Note: if you're using a template for the document that would also be the best place to store the macro attached to the macro button.)
Once this is set up, all your code needs to do is insert the BuidlingBlock at the end of the document.
My company creates workbooks for clients that contain ActiveX controls (in most cases we need the extra functionality as compared to Form Controls). When we create them, they work fine on our end, but when we zip them up and send them to our clients, they open the WB and the ActiveX controls are no longer ActiveX controls, if you right click it, it behaves like a picture.
I feel like this is due to the MS ActiveX debacle. I have had them run the Fix It and making sure all the MS Office components were closed, and had them reboot, but still nothing.
I am pulling out my hair, and have asked on other forums if anyone else has had this issue, and what they have done to fix it. Thanks in advance.
Could you please check in client system whether macros and active x controls are enabled in Trust center setting?
https://support.office.microsoft.com/en-us/article/Enable-or-disable-macros-in-Office-documents-7b4fdd2e-174f-47e2-9611-9efe4f860b12?CorrelationId=fe6a4d24-f4d9-4c6b-afa0-40d2828ad22e&ui=en-US&rs=en-US&ad=US
use above link if needed.
Try closing excel and deleting the .EXD files from your computer.
Source: http://www.mrexcel.com/forum/excel-questions/296750-command-button-turned-into-image.html
While saving the Excel document, save it as "Macro enabled workbook".xlsm
In my case, the worksheet prompts a non responsive error sometimes. When I reopen it, Excel repairs it and turns all active X check boxes (sometimes drop down list and command buttons) into images. It happened many times and I had to spend a lot of my time recreating them and liking to cells.
I experienced a similar problem when Excel repaired a file; this may be similar to what's happening with the Zipped file. FormControl Buttons don't appear to have the same problems but I see you want to keep the additional functionality of the ActiveX Control.
You may be able to make use of the code I created by inserting one Form Control button that runs the Sub RepairMissingButtons() that your clients can press to restore the images to CommandButtons. This currently fixes buttons for any selected sheets, so you'd want to first identify which sheets need to be selected (or add a form control button on each sheet that needs the repair done).
You'd need to modify the Sub CreateButton() to meet your needs (currently requires hard-coding the Caption, BackColor and any other ActiveX properties that may have been lost by the button being converted to an image):
Reverse Excel ActiveX command buttons erroneously converted to images after corrupted file repair
Having this problem, activex controls sometimes change to pictures.
Many places around the internet the answer is: Use form controls, well as far as I can tell form controls don't actually do anything useful.
Even Microsoft's support site says, recommend using form controls, how can that be the answer. being able to interact with VBA is as far as I can tell the only reason to use Microsoft applications instead of free ones.
I'm currently using Word documents as templates where blanks have to be filled dynamically/programmatically in PwoerBuilder.
This has always worked fine until the company moves on Windows 7.
In short, the Word application is opened and made invisible.
Word.Application.Visible = false
Except that sometimes, and I don't know why, once the template is accessed, Word opens itself just as if I had double-clicked the template byself through the Explorer - but I didn't.
So, it asks whether I want to open it in read-only mode, since the application already has a handle on the file. And even if I click [Cancel] not to open the file, Word opens with no document, then the application crashes.
It reports PowerBuilder System Error 35.
Error Number 35.
Error text = Error calling external object function open at line 24 in function of_fusion of object n_cst_9999.
The external object that the application is trying to call a function against is Word.
oleobject lole_word
lole_word = create oleobject
lole_word = ConnectToNewObject("Word.Application")
lole_word.Documents.Open("templatefile.docx")
It may work for a few documents, and after a few, the problem comes up. This is the first time ever I meet with this issue.
I'll be glad to answer anyone's question who's trying to help.
Will, you may try setting DisplayAlerts and FeatureInstall properties on Word Application object.
That hid most of word alerts for us. (The code is from C# project and may not be exactly what you need)
Word.Application.DisplayAlerts = Word.WdAlertLevel.wdAlertsNone;
Word.Application.FeatureInstall = 0;
You may also try making a copy of the file before opening it to avoid accessing same .docx from different threads - if that may be the case.