I need some advice on how to go about a particular issue I'm trying to build a work around for, but keep finding myself between a couple of poor options.. The application has a large collection of word doc templates. The application is to on the fly generate one of the templates and fill in the bookmarked values.
I have a few options on how to go about this...
Use the Interop Library: I pretty easily fill in an actual, templated document with the Interop library by going through and grabbing all the bookmarks and filling them in and saving the document again.
Issue: I need to be able to support version of Word from 2003-2010; version becomes a concern here... if I link against the wrong version of the Interop.Word, might it cause compatibility issues for users of older versions? I don't have much to test with here, so I'm not sure...
VBA Macro: I've actually used this method to build excel spreadsheets before; write fields to a csv, read into a new document generated from template via VBA, and ta-da, new document.
Issue: Security settings on end-user PCs are likely to be extremely strict. VBA likely to be disabled.
Is there a better way of going about this that I'm not seeing? Is the Interop version likely to be less of a big deal than I thought? Other than OfficeXML, which is a catastrophe for the documents we're using (I've looked..), is there another good possibility?
Edit: submitted early.. damn browser -_-;
VBA is usually blocked in documents and templates that are opened. But templates in the Word startup directory are allowed. I'm not sure about Word 2007 and 2010, but in Words 97 to 2003 there was a wrdstart directory that could contain templates that were loaded on startup of word. The normal.dot file was in there, and you could add your own to contain scripts, macros toolbars and other stuff.
I think this hasn't changed in essence since then, although I don't do a lot of Word development anymore, so I'm not sure.
[edit]
Yes, it still exists. In Word 2010 you'll find the setting in File -> Options -> Advanced -> File Locations (button). There is a 'Startup' setting, pointing to a directory. Templates in this folder will be loaded on startup and their macro's should be able to be executed.
Check File -> Options -> Trust Center -> Trust Center Settings (button). There, you can specify allowed documents, and trusted location. The wrdstart directory is in there, but you can add your own.
Related
I want to make an installer for programs (games) written in VBA(Office Word).
The problem I need an answer for:
It obviosly uses macros. For these to run the user suppose to change the security settings of word. But I can’t hope that they are able to do that or willing to make that extra effort. So I was wondering if there was a way to do that with the installer. You know, ask them if they want to allow it, and then the program would change the setting of office that the game could run.
Does any of you know if that is possible and if it is what the program is that I should use that for?
Macros cannot change the security level that allows macros to run, because
1 if macros aren't allowed to run they don't run so they can't do anything
and
2 because otherwise bad people would do it without asking and steal all your money from your bank account whenever you opened a word document
However, if your installer is written in some other language it could possibly change the setting. if it was run with sufficiently elevated privileges. But you shouldn't do this for all word documents because bad people. Instead, set up a trusted location - a folder whose file's can run macros, and save your file there. That maintains security for general word documents while allowing your file to run.
So I'm having to run someone else's excel app on my PC, and I'm getting "Can't find Project or Library" on standard functions such as date, format, hex, mid, etc.
Some research indicates that if I prefix these functions with "VBA." as in "VBA.Date" then it'll work fine.
Webpages suggest it has to do with my project references on my system, whereas they must be ok on the developer's system. I'm going to be dealing with this for some time from others, and will be distributing these applications to many others, so I need to understand what's wrong with my excel setup that I need to fix, or what needs to be changed in the xls file so that it'll run on a variety of systems. I'd like to avoid making everyone use "VBA." as an explicit reference, but if there's no ideal solution I suppose that's what we'll have to do.
How do I make "VBA." implicit in my project properties/references/etc?
-Adam
I have seen errors on standard functions if there was a reference to a totally different library missing.
In the VBA editor launch the Compile command from the menu and then check the References dialog to see if there is anything missing and if so try to add these libraries.
In general it seems to be good practice to compile the complete VBA code and then saving the document before distribution.
I had the same problem. This worked for me:
In VB go to Tools » References
Uncheck the library "Crystal Analysis Common Controls 1.0". Or any library.
Just leave these 5 references:
Visual Basic For Applications (This is the library that defines the VBA language.)
Microsoft Excel Object Library (This defines all of the elements of Excel.)
OLE Automation (This specifies the types for linking and embedding documents and for automation of other applications and the "plumbing" of the COM system that Excel uses to communicate with the outside world.)
Microsoft Office (This defines things that are common to all Office programs such as Command Bars and Command Bar controls.)
Microsoft Forms 2.0 This is required if you are using a User Form. This library defines things like the user form and the controls that you can place on a form.
Then Save.
I have experienced this exact problem and found, on the users machine, one of the libraries I depended on was marked as "MISSING" in the references dialog. In that case it was some office font library that was available in my version of Office 2007, but not on the client desktop.
The error you get is a complete red herring (as pointed out by divo).
Fortunately I wasn't using anything from the library, so I was able to remove it from the XLA references entirely. I guess, an extension of divo' suggested best practice would be for testing to check the XLA on all the target Office versions (not a bad idea in any case).
In my case, it was that the function was AMBIGUOUS as it was defined in the VBA library (present in my references), and also in the Microsoft Office Object Library (also present). I removed the Microsoft Office Object Library, and voila! No need to use the VBA. prefix.
In my case, I could not even open "References" in the Visual Basic window. I even tried reinstalling Office 365 and that didn't work. Finally, I tried disabling macros in the "Trust Center" settings. When I restarted Excel, I got the warning message that macros were disabled, and when I clicked on "enable" I no longer got the error message.
Later I re-enabled all macros in the "Trust Center" settings, and the error message didn't show up!
Hey, if nothing else works for you, try the above; it worked for me! :)
Update:
The issue returned, and this is how I "fixed" it the second time:
I opened my workbook in Excel online (Office 365, in the browser, which doesn't support macros anyway), saved it with a new file name (still using .xlsm file extension), and reopened in the desktop software. It worked.
Even when all references are fine the prefix problem causes compile errors.
What about creating a find and replace sub for all 'built-in VBA functions' in all modules,
like this:
replace text in code module
e.g. "= Date" will be replaced with "= VBA.Date".
e.g. " Date(" will be replaced with " VBA.Date(" .
(excluding "dim t As Date" or "mydate")
All vba functions for find and replace are written here :
vba functions list
For those of you who haven't found any of the other answers work for you.
Try this:
Close out of the file, email it to yourself or if you're at work, paste it from the network drive to your desktop, anything to get it to open in "protected mode".
Now open the file
DON'T CLICK ANY ENABLE EDITING OR THE YELLOW RIBBON
Go to the VBA Editor
Go to Debug - - Compile VBA Project, if "Compile VBA Project" is greyed out, then you may need to click the yellow ribbon one time to enable the content, but DO NOT enable macros.
After you click Compile, save, close out of the file. Reopen it, enable everything and it should be OK. This has worked for me 100% of the time.
In my case I was checking work done on my office computer (with Visio installed) at home (no Visio). Even though VBA appeared to be getting hung up on simple default functions, the problem was that I had references to the Visio libraries still active.
I found references to an AVAYA/CMS programme file? Totally random, this was in MS Access, nothing to do with AVAYA. I do have AVAYA on my PC, and others don't, so this explains why it worked on my machine and not others - but not how Access got linked to AVAYA. Anyway - I just unchecked the reference and that seems to have fixed the problem
I've had this error on and off for around two years in a several XLSM files (which is most annoying as when it occurs there is nothing wrong with the file! - I suspect orphaned Excel processes are part of the problem)
The most efficient solution I had found has been to use Python with oletools
https://github.com/decalage2/oletools/wiki/Install and extract the VBA code all the modules and save in a text file.
Then I simply rename the file to zip file (backup just in case!), open up this zip file and delete the xl/vbaProject.bin file. Rename back to XLSX and should be good to go.
Copy in the saved VBA code (which will need cleaning of line breaks, comments and other stuff. Will also need to add in missing libraries.
This has saved me when other methods haven't.
YMMV.
I've been asked to create a macro to update a few hundred or so Visio drawings, and keep them updated.
The update involves putting all objects of a certain type on their own layer - simple.
Now, this is easy enough to do, but when a user adds a new object some time in the future it will likely be on a default layer. So I had hoped to be able to include a VBA macro which is triggered by the Save event to re-assign objects to their layers.
The problem here is that I'd need to include this macro in every document since Visio doesn't have an application level VBA project.
Is there any way to introduce a VBA project to ALL Visio documents using code (VBA or otherwise)?? Or is there an alternative I might not have considered? Unfortunately an Add-in is not really an option due to available resources.
You have a couple options here:
Force every user to allow programmatic access to the VBA project for their documents, and use VBA automation to add code. This works nicely when you have programmatic access, but this can be difficult to assure.
If you're not using Visio 2013, you can actually save a document as VDX (xml) and replace the data for the VBA project with your own (you'd save out a document as VDX manually, and copy out the chunk of data for the VBA project). As I said, this wouldn't work with Visio 2013 since they seem to have eliminated the VDX format. You probably can get away with something similar with the VSDX XML format for 2013.
You can 'migrate' everyone's documents to a new VST file you provide. This would just involve copying and pasting all the content from a document into the new document that has your code in it. You have to be careful though to make sure all the document- and page-level data comes along, too (meaning DocumentSheet and PageSheet and any Document XML properties that may be important, and attributes like Author, Description, etc...)
Item 1 is the easiest, aside from the pain getting programmatic access to VBA Projects, unless you can have people send you documents to migrate.
Part of my job right now is to build some dynamic functionalities into Microsoft Office documents. The only means I've found to do this is through VBA - and thus, the VBA editor which comes built in to Office docs.
The VBA editor is awful. It's missing a million different functionalities that modern development environments need to support. But the worst part is that I'm a hard-core Vim lover, and the VBA editor is barely any better than notepad.
So: Is there any way I can effectively use Vim to do VBA programming? Short of copy-pasting my code into the VBA editor from a different window when I want to try it?
I've never used the VBA editor, but here's something I've done with MS Visual Studio. (MSVS's editor does have some nice features, but I still prefer vim for most editing.)
I open or create the source file in MSVS. I then get the full path to the file (by right-clicking on the tab and selecting "Copy Full Path"), and open the same file in vim in a different window.
I use alt-tab to bounce back and forth between vim and MSVS. When I make a change in vim, I use :w to write the change, then alt-tab back to MSVS. The MSVS editor notices that the file has changed on disk and offers to read the updated version.
Alternatively, if I change the file in MSVS, I write the file (File > Save ...), then alt-tab to vim and use :e! to read the updated file into the vim buffer.
There's no need to copy-paste the code, since both editors are operating on the same disk file. I just have to be very careful not to make changes in both vim and MSVS without writing the file to disk.
It's ugly, and it's not for everyone, but it works for me. Maybe it will work for you.
I use Cygwin, so it's actually a little more complicated; Cygwin programs, including vim, don't recognize Windows-style paths. I can do this:
vi $(cygpath 'WINDOWS_PATH')
where WINDOWS_PATH is pasted from the full path I get from MSVS. The single quotes are necessary to keep the shell from interpreting the \ characters. If you're using a Windows native vim, this step isn't necessary.
That's an interesting opinion. I used VI briefly about fifteen years ago and based on that I contend that the VBA editor is far more suited to its purpose than VI (or VIM?) would be. Is there one particular piece of functionality that it is missing from the VBA editor that precludes you effectively using it for its purpose (editing VBA)? VBA has not been enhanced for many many years, but the fact is it can't be killed off because everyone finds it so easy to use.
If you wish you can write some piece of code in your preferred language that manipulates your word document via COM objects (if it supports that). Then you can call your external piece of code from a simple stub within your Word document. You need to get around some security constraints though in your Word document.
For example I could write some code in VBScript or VBA or Powershell or .Net that manipulates a word doc. I can call that from a small piece of VBA (that might be attached to a button or something in the standard word toolbar)
I'm going to have to write a number of vba modules for a project I'm working on, and would prefer to use SciTe to the built in editer in Office.
SciTe allows you to redirect the effect of hitting F1 to a arbitary command with the selected text as an argument. Is there anyway of using this functionality to search the relevant .chm files?
I'm guessing not, given that the help for vba is spread across multiple files, but I'm hoping someone can prove me wrong...
I'm especially interested if anyone can suggest a way to find out which chm file a particular libraries help resides, just from the fully delimitered name of the function.
Another approach is to use the HTML Help command line program HH.EXE to either show specific pages, or to decompile a particular CHM into HTML files.
Go to the folder mentioned by Lunatik in a command window and enter this command:
hh -decompile html vbaac10.chm
^^
# ac is for Access; use xl for Excel, wd for Word, etc
This will create an "html" folder below it and fill it with most of the files that went into creating the CHM file. The resulting HTML files can be opened directly in your browser, although they won't find their related style sheets or scripts which are addressed by their locations in CHM files. The style sheets and scripts do get extracted though so you can work with them too.
Also take a look at the XML files in the 1033 folder like VB_ACTOC.XML - this is the Table of Contents for the Access VBA help. It contains topic nodes with labels and urls for each item in the help file:
<topic>
<label>CheckBox Object</label>
<url>mk:#MSITStore:vbaac10.chm::/html/acobjCheckBox.htm</url>
</topic>
The mk:etc... url can be put on the HH command line to open that topic in a regular HTML Help window. Also, it shows the source CHM filename, and the relative path of the file when decompiled.
hh mk:#MSITStore:vbaac10.chm::/html/acobjCheckBox.htm
Working from these files, you could put together a script to find/grep files by keyword and show them in a browser, or you could reengineer the files into some sort of database or other lookup capability to work with SciTe's command based help system.
Some sites with more info about using HH.EXE:
HTMLHelp command-line
tips on using the HH command line and links to other sites
KeyHH 1.1
an alternate/supplemental program to HH.EXE for working with CHM files
The main files are held (for Office 2003 anyway) in Program Files\OFFICE11\1033, but accessing pages within them could be a bit tricky as Microsoft have gradually had to reign in the ability to delve into CHM files over the years due to security concerns.
This page (download) has some good info on what might still be possible as far as linking to specific pages inside a CHM
Having said that, I don't think this file is the default help shown to most users nowadays, but it's close enough, missing only the Office 2007 pimping most of the time. The online help seems to be set as default unless you specifically disable it during the Office install. The URLs are, I think, not very SEO friendly so couldn't be guessed. I suppose you could borrow a sneaky trick from scammers and craft URLs that point to the top link on Google, thusly: Range.
EDIT: Google cache link?
Inspired heavily by Lunatik's answer, adding:
command.help.$(file.patterns.vb)=http://www.google.co.uk/search?hl=en&newwindow=1&q=site%3Amsdn.microsoft.com+%222003+VBA%22+$(CurrentWord)
command.help.subsystem.$(file.patterns.vb)=2
to my vb.properties file gives me a reasonable work around (loads a Google search results page with search criteria of:
site:msdn.microsoft.com "2003 VBA" $(CurrentWord)
Obviously no guarantees of it taking me to a helpful page, but then the inline help in the VBA editer isn't all that reliable on that one either...
Can anyone who knows SciTe better suggest a more elegant solution?