I have a VBA macro which runs in Word 2003. It is one module and the code attached to a userform, and it goes to about 30 client sites. When I first rolled this out I sent someone round to each site to place a .dot template in the Word Startup folder of each of 30 boxes, which then makes the macro appear as a button on the toolbar for each user.
All the users are internet connected.
The location of the .dot template varies from machine to machine, so "installers" would be out of play I presume?
I am anticipating that the macro made need to change from time to time. Is there any way I could get the user to press a button to get the macro to update itself?
Whether its push button or auto run checking for update, I would presumably need to know how to determine where the macro is running from (path) without a document necessarily having been saved, and how to find path to the Startup folder tools>options>file locations but programatically .
This can be done.
create 2 .dot files, loader.dot (checks for updates) and worker.dot (the main macro you are using and want to be able to update automatically).
the first loader.dot should go into C:\Program Files\Microsoft Office\OFFICE11\STARTUP
This is a trusted location and the macro will be loaded into any Word document. Use an AutoExec() subroutine to ensure it runs whenever a word doc is loaded.
worker.dot can go in any fixed installation location e.g. C:\yourapp\worker.dot
The logic in loader.dot is remove any reference to worker.dot (I had to enable trust of VBA model in macro security settings) check for an update using an http call, if new version available download it overwriting worker.dot, then add reference from file specifying worker.dot
I'm not sure that the user-presses-a-button model is ideal.
I'd look into building a "loader" template. Its job would be to run at startup and look for updates to the template/macro you already have and download/install/whatever such files when they change. Then load whatever's installed locally for use.
You should also think about whether it's a problem if an update is available but someone doesn't use it (perhaps they started Word before the change was uploaded, or they're offline). Also, do you need to know what version people are using? Have your loader report back, via HTTP, email or some other method (Twitter?)
Any such loader needs to either very stable (otherwise you just replace chasing around replacing the target template with chasing around replacing the loader) or able to update itself when necessary.
Related
I am making a little program and I need to be able to remove the Lock attribute from all files (no matter the extension of those files) in the specified directory. I haven't find any way to do so on the web so far, so I really have no idea how to start a basic code for that job, so all I can really do is give you the elements of my Windows Form:
txtDirectory: This is where the directory is being
displayed/selected. All files in the displayed directory needs to be
getting the Lock attribute from them - see btnConfirm to know more.
btnSelectDirectory: This button opens the directory seletion
dialog. This section does not need any code - but feel free to add
code if you think it could improve my program.
btnConfirm: This
button is where, when clicked, all files in the specified directory
will be removed from the Lock attribute. This is what I really
need help with.
How can I do so?
I have a word document that has a few userforms and options to auto create an entire document. It works great on all of the installations I have tried from 2007 to 2013. The problem is that one user on one computer gets compile errors when it the user form is launched. The compiler complains that controls do not exist that actually DO IN FACT exist. I had him create a temporary account, just a simple test account, no admin permissions and it runs fine.
I have have tried killing the usual suspects
-.dotm files
- normal.dot files
- wiped word start up folders
- I have reset the word registry key
- I have renamed the appdata\Microsoft\office, appdata\Microsoft\word etc etc etc.
There are no missing references.
More oddities:
it complains about a missing control, lets just say frm.txtname.
I cut the sub that contains the reference and paste it at the bottom POOF it no longer believes the control is missing but...it finds another one to complain about.
I know it is something wonked up in the profile but I cannot find it.
Try this: In VBA editor open Tool bar and click References. You will see the list of references. Unclick those who starts with "MISSING". It should work.
I had a bunch of macros that I had in C:\Users\userx\AppData\Roaming\Microsoft\Templates that were always available in word 2010 but since upgrade to word 2013 I cannot run them. Word apparently does not automatically load them anymore. I used to just do alt F8 and pick from the list. I also had a few added to the quick options bar but they are gone also.
Searched this site and MS website and can't seem to find a solution. Is there another location that I need to move the files containing the macros to or is there some other action that I need to take so I can run them again?
My guess is this is already answered here and I am just not searching for the right things. My apologies if that is the case, please just point me to the appropriate post.
You can place a shortcut to the templates containing your macros in the following location
C:\Users\%username%\AppData\Roaming\Microsoft\Word\STARTUP
That will make your macros available whenever Word opens and restore the Alt+F8 functionality you're looking for. If you add toolbars to your templates, those will also automatically be attached to the Normal template when you open Word.
In Visual Studio VSTO, how can I specify the document to open each time I run the project to debug it?
By default, it always opens a blank document and of course I want to test against features that would already be present in a document.
I tried as Cor_Blimey suggested but it opens only the specified when something changes (haven't figured what yet). In addition breakpoints don't work at least in VS2013 implementing the upper solution.
So what I did is to open the specific debugging/testing file each time the add-in is started up.
It works excellent, breakpoints are functional, no blank workbook is loaded and changes in a sheet a available in the next debugging session.
In order to avoid that the file is opened in the released add-in I put it in #if DEBUG.
More information about that method are here but it has as to be used with precaution as described here.
private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
#if (DEBUG)
this.Application.Workbooks.Open("C:\\Users\\c563368\\Documents\\Visual Studio 2013\\Projects\\...\\debug.xls");
#endif
}
But there is one disadvantage, as long as you debugging environment (visual studio) is running, Office will always open the add-in build from the debug folder.
You can avoid this by running an the office application as external program, as described here.
You need to use the command line you can set to run on a successful build (there is no way to only get it to run on Debug (as in F11) and you cannot set it on a per Configuration basis. However, there is a good workaround to get it to only do things on the Debug configuration etc.
The basic behaviour is:
Open the solution. Open the project's properties. Go to Build Events. In Post-Build Event Command Line enter in the path to Word (e.g. "C:\Program Files (x86)\Microsoft Office\Office14\Winword") (or if it is in your %Path% then just Winword) and pass in the path to the document you want opened as an argument. This will open Word and the document on every successful build (you can set the trigger to being all builds, whether successful or otherwise etc)
What I prefer to do, however, is simply point it to a batch file, passing in the details about the build event as arguments to the batch file. Then, within the batch file, I run the logic to decide if it should launch Word, open a document etc.
For example, you can point it to
$(ProjectDir)buildScript.bat "$(ConfigurationName)"
Then within the batch file have something like
if %1=="Debug - Excel" "C:\Program Files (x86)\Microsoft Office\Office14\excel.exe" "%~dp0\testbook.xlsx"
This will run a batch file called buildScript in the project directory. The first argument (%1 to access in the batch file) will be the configuration. You can therefore set the batch file to launch Word and pass in the document as the argument if the config is e.g. "Debug" but not if it is "Release", thereby sidestepping the limitation within VS2012 Post-Build Event command line.
Edit:
A list of switches for Word can be found at http://support.microsoft.com/kb/210565
What you need to instruct Word to do will depend on the type of addin you are making:
If it is a standard COM addin then, so long as the DLL is registered and you have set the registry entries (or selected it in the Word addin settings) to open the addin then it should open when Word opens.
If it is an addin document, however, then the procedure is different -> try playing with the commnd switches to instruct Word to open the particular addin document.
I am more familiar with Excel COM addins, so you will have to experiment with the specificities of a Word addin. But the basic principles are to use the post-build event commnd line, coupled with the right switches and arguments to Winword.
Hope that helps.
The simpliest way to achive it is to replace .docx / .xlsx file in solution location
I had a VBA project in outlook with a few email macros - but after a PC crash they are all gone and all I see is a fresh 'Project1' when I hit Alt+F11
I'm not a VBA programmer, but had a collection of handy macros for email sorting etc. I would not like to have to code them again. Anyone know where the code files should be on the filesystem so that I might rescue the code?
This page has some really good insight on where Outlook keeps all its stuff. It suggests the following:
All Outlook macros are stored in a single file named VbaProject.otm in the user's %appdata%\Microsoft\Outlook folder, which will be a hidden folder on most systems.
Now, the problem is that if you do not see them now, then you probably won't be able to restore them from that location: there is probably either an "empty" project there or no project at all, but if that folder is being backed up, you might be able to restore it.
Moving forward, you might consider exporting your macros periodically in case this happens again, either through the VBA IDE (right-click and select Export File...) or using one of the tools mentioned in the linked article (like the Office Profile Wizard).
Ok. things to try to fix this...
I assume after the problem occured you tried logging back into the same windows user account, and the same Outlook profile.
Create a new windows login to the machine in question.
Login to this account and open Outlook, this will create a new outlook profile. make note of the profile name (to find this: Control Panel > Mail applet > Show Profiles...)
Now Exit Outlook, and make sure it is not running (check for outlook.exe in task manager).
Open Windows Explorer.
Copy (don't cut) the existing VbaProject.OTM file. (if it has any other name than that, first rename it to VbaProject.OTM, then copy).
Navigate to C:\Documents and Settings\USERNAME\Application Data\Microsoft\Outlook
(or use the environment variable notation %appdata%\Microsoft\Outlook for vista/win7)
Rename the existing VbaProject.OTM to VbaProject.OTM.OLD
Paste the VbaProject.OTM from step 5 into this folder.
Reopen Outlook and test (i.e. Alt + F11).
Good luck with recovery.
If this doesn't work do you remember adding self signing certificate at all? If so have you got a copy of the cert? you can try reinstalling it into the certificate manager (certmgr.msc)
copy/install it to the Certficiates - Current User\Personal\Certificates hive.
I just found this note from Sue Mosher (outlook VBA guru):
"AFAIK, once an .otm file is corrupted, it can't be recovered. That's why I recommend that people who rely on VBA code export their modules or backup the entire file. "
All macros are embedded into an OTM file, under the following location:
C:\Users\(***Your User Name***)\AppData\Roaming\Microsoft\Outlook\VbaProject.OTM
To restore, replace this file with the older one, it should work
Ran into this same problem.
First reviewed the .otm file mentioned by #Anonymous Type and #Dave DuPlantis
Not corrupted... hmm
I checked my Ribbon in Outlook for the Developer tab. It was missing and simply re-adding it to my Ribbon fixed my problem.