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.
Related
If someone have to carry on working on an Excel VBA project/module after the previous developer left the company, how do they safely change a global variable name?
These global variable names can be problematic if they are misleading, misspelled, look like another variable, don't follow the chosen convention, etc.
Changing them with a Search/Replace is a problem because sometimes it's a word that appears in comments.
Changing them by Copy/Pasting is a problem because it's long and you can miss some, especially if there are a lot of occurrences or if you change it to something similar.
Is there a way to do this safely via the Excel "IDE", or via another tool?
What you need to do here is called a refactoring - you need to make a possibly dangerous change to the code, without affecting its behavior. Do it wrong and the code breaks!
Renaming an identifier that's used in one or more places, is a rename refactoring.
Most modern IDE's have such a feature (and several other refactorings). However the VBE was at the height of its glory well before Visual Studio was the full-featured tool it has become since then - heck, the VBE was Visual Studio (6.0) in 1998!
So you really have two options:
Do the refactoring manually - the IDE's search & replace functionality (Ctrl+H) can be dangerous here, because it treats code as simple text, without semantic understanding: you need to review every single occurrence individually, or risk renaming an identifier that was not referring to the variable you're trying to rename.
Use a 3rd-party tool - I don't know any VBIDE add-ins that understand the code deeply enough to allow safely refactoring VBA code, other than the open-source Rubberduck project, which I've managed since October 2014). This add-in parses your entire project, builds a symbol table, and lets you navigate and, yes, refactor/rename any identifier, automatically updating all call sites.
Note that Rubberduck is a very active open-source project, constantly improving. Parsing VBA is hard, and getting the VBE functionally on par with modern-day IDEs isn't a small undertaking, nor is it easy... but it's fun, and yep, it works.
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'm currently making a personal account manager program and right now I've achieved creating one but there is a visible .accdb file along with the .exe itself. And it is not very safe since the .accdb can just be opened.
Is there anyway to achieve this without having a visible database? Or any secure way in achieving this would be appreciated.
SQL Server Compact Edition supports encryption.
https://technet.microsoft.com/en-us/library/gg592949(v=sql.110).aspx
And no, you aren't going to be able to embed it in the .exe unless you come up with a tremendously complex scheme of recompiling the .exe every time the database changes.
You could set the hidden attribute on the database file, though, to try to obscure it. It just depends on whether your goal is to stop competent hackers (which it won't do) or just to stop a user from accidently deleting or renaming it (which it will do). A hidden, encrypted, file would do both.
When I install an add-in (via the checkbox) what are the rules / mechanics governing how long that add-in stays installed? It seems that it is installed on the application level, meaning that it applies to any workbook in the excel application, until you uncheck it yourself. If this is correct, this means that as long as a user installs the add-in themselves, they should be fine; but they will have to install it that first time (which could be done programmatically).
Regarding VBA references, I imagine these do not need to be 'checked' every time- meaning it is in the scope of the document. But if this is true, why do people recommend using late binding methods when the software is ready to be distributed? Is late binding really just to make it compatible with different versions, but not necessarily to make it so the DLL is 'checked' as a reference? Under this assumption, as long as everyone uses the same version of Excel as the me, would it be safe to forego late binding all together, and just add the references manually?
Using late binding is better because you can't guarantee that every system will have the same references available. So you should only select references that you can guarantee will be on every machine and distribute the DLL files for the rest.
As far as scope, the public subs/functions/variables in your add-in will be available to anything in the application as long as it is installed and active. The references in the add-in will be available only to the routines in the add-in.
Add-ins are installed to the Application-level. You can fine-tune how an Add-in may be exposed (or not) to various Workbook(s) using Ribbon XML if needed.
as long as a user installs the add in themselves, they should be fine; but they will have to install it that first time
Yes, they'll have to install it.
Regarding VBA references, I imagine these do not need to be 'checked' every time- meaning it is in the scope of the document.
Yes, version control. It also saves you the hassle of having to try and programmatically add references. This can be done by path (which requires knowing the OS, version, etc. ) or the GUID (I've never actually been able to do this successfully). Both of these would then require error-trapping (what if the path doesn't exist or is otherwise inaccessible? etc.). So just use late binding.
While developing using early binding is helpful because of the intellisense, from a user perspective, there is generally no observable difference in how they might perform although EB is arguably faster, the difference is usually negligible for most applications. Related, if while using EB you rely on the New keyword to instantiate objects, I believe that the CreateObject function which you would use with LB is actually faster. This is probably not noticeable, though.
can I forego the late binding all together, and be safe by just adding the references manually?
I would simply do the development with EB, and then modify the code to late-bound objects before compiling the Add-in.
I've had a very difficult time implementing an Add-in in Excel.
I've got buttons on a worksheet which reference code in the Add-in, and I've also got code in the worksheet which references functions in the Add-in. What was really throwing me off, was that I could inactivate the Add-in (options, add-ins, Manage, uncheck) and the code continued to access the add-in. This was particularly frustrating during development and debug of the Add-In, because what I wanted to do, was to inactivate the Add-In (during development) and have my application worksheet reference the open Add-In .xlsm development file. What took me a while to figure out, was that due to the code "References" in the application worksheet, it was still calling to the code in the .xlam file, not the .xlsm.
Once I figured this out, things when smoother, but now, each time I make a change and want to test, I need to close my application, Inactivate the Add-in, Close Excel, Save my .xlsm as .xlam in the default Excel Add-Ins directory (which BTW requires administrator rights), Open excel, Activate the Add-in. [Close Excel], Open my workbook application. A throughly exhausting process. Perhaps I could skip the last [Close Excel] step if the add-in becomes active immediately when checked.
And then dealing with users on Win10 and Win7 really complicates things. Different path to default Add-in folder. Users have to change references path, etc. Very ugly. Very Microsoft.
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.