Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
I have prepared lots of Excel based Tools using excel macros. In these Excel Sheets user normally browses Excel files or inputs data as guided by the tool and then runs my macros to generate a desired output. Everything is working fine.
However, instead of distributing these tools as Excel sheets, can I convert my codes to a exe file and distribute it to users who can run it there?
I searched a lot on Excel to exe related threads but didn't get a satisfying answer hence thought of starting a new thread.
This answer might not be satisfying too but the fact is that Excel is no programming tool to produce stand alone applications (exe).
Therefore you need to re-write your project using a real programming language (and tool) like VB.NET or C#. VBA (Visual Basic for Applications) is meant to run in applications as its name says (like Excel or other Office applications) but not stand alone.
There is no way of just converting the code (by pressing a button or something) you will need to re-write the whole project/tool completely (by hand) in another programming language if you plan to use your application stand alone (exe) without Excel.
Please note that even if VBA and VB.NET use similar syntax you cannot just copy the code. These are 2 completely different languages and the code needs to be re-written. Even if the result would look similar it is not the same.
Your solution is not the answer to your need. What you actually want is an Add-In file that you can distribute to your users. This file extends Excel and gives users access to your tools, but can be password protected and hidden so users can't mess with it . At it's simplest it's just a case of saving the workbook containing your code as a file of type Add-in, but you do need to rewrite your code to make explicit which workbook you are working with, since ThisWorkbook in your code is the add-in, and ActiveWorkbook is the file that the user has open while using your addin. You will also need to develop menus to give users access to your tools, since they can't see the add-in.
You can only do that if you do it outside excel, write a program in a Windows development tool which is able to communicate between applications. You can use many Microsoft development platforms for this, f.e. C#.
What you want to do is start a process to interfere with another process.
How to do it depends a lot on the targetted windows-version. It is not an easy subject, and I don't know if you really want to go this way. But if you do, Google on inter-process communication and Windows.
This is a nice overview article:
https://learn.microsoft.com/en-us/windows/desktop/ipc/interprocess-communications
Related
I recently started writing VBA macros, even though I never learned VBA. So basically I am translating my python knowledge to VBA, which works most of the time.
However I want to improve my coding skills, especially when it comes to working with other people.
Usually I am writing a Macro and then install it on the computer of my colleagues, so that they can use it as well. But the way we develope the macro is currently a try-and-error approach, so I have to edit the code quite often. Currently I just copy paste the new lines into an Email and the person has to exchange that line by themselves.
My Question: How do professionals handle updating VBA Macros? Is there something like "patches"? Or can you have a shared "Personal.xlsb", so that all changes are automatically updated for everyone else as well? I am the only person editing the code anyway, the others just use it.
I googled a lot and also looked through stackoverflow, but only found this: How to write a patch to Excel VBA codes? where the answer basically was, that you can't write patches. But there surely must be a way, to update my macros in a better way, right?
Thanks in advance!
I've put together a simple Excel database that performs a few macro functions and I need to distribute this database to a few people - but they cannot see how the macro function actually works (stupid rules I have to follow!). What is the best way to achieve this?
I've done a bit of research and I found two ways:
Password protect the VBA project; but this is apparently very easy to break using readily available tools online (it would be in the best interest to the people I'm sending this to find out how the macros and functions work; so I'm almost 100% sure they will try to get into it.. hence a password protection seems inadequate.
Move to a fully compiled language like C++; my skills are very limited to VBA on Excel and Access so this being the ideal solution; isn't a solution for me :(
Are there any other ways? I thought of having a 'master excel document' with all the macros in that and then send 'children' databases to the end users and have the 'children' databases connect to the 'master' - is something like this possible? By hosting the master online or even sending the end users the master but making it completely inaccessible unless accessed by the 'children' databases?
You can create Automation Add In.
An Automation Add In provides several advantages
Execution Speed : An Automation Add In written in VB6 is compiled to
native machine code which runs much faster than the interpreted VBA
languange.
Security : Unlike an XLA add in, you never distribute the source code to the end users. If your code has proprietary information or
intellectual property value, that remains safely protected on your
own computer. It is never distributed to the user. Your code can
never be compromised.
http://www.cpearson.com/excel/automationaddins.aspx
There aren’t too many ways to protect your Excel VBA code reliably.
You can try to use passwords or VBA obfuscators, but all of that protection is limited. Passwords are easy to break, and obfuscated VBA code can still be traced back and recovered.
The other answer to this question mentions using VB6, but that limits your code to 32bit Excel. Also VB6 can be decompiled by VB decompiler.
Converting your code to a compiled language is indeed the best way to protect your VBA code, but be warned that in this case not all code is created equal.
Converting your code to VBA.NET is a flawed solution because the compiled code of .NET assembly can be converted back into the original source code.
Converting your VBA code to C or C++ is the most effective form of protection, but this takes a lot of experience and effort since C/C++ and VBA are very different languages.
I would suggest you have a look at a tool called VBA Compiler for Excel (https://vbacompiler.com/how-to-compile/). It compiles your Excel VBA code into a DLL file with a click. You do not need any knowledge of C or C++ languages to use it.
If you're still looking for a good way to protect your Excel VBA code from copying or tampering, then you should consider the Excel VBA compiler of XLS Padlock.
Because XLS Padlock offers an integrated VBA compiler that can compile your VBA code into binary code, making it completely secure and inaccessible to others.
it's really binary code and not simple obfuscation.
You open the VBA compiler of XLS Padlock, move some vital parts of your existing VBA code into it (subs or functions) and it compiles live. You can then invoke this compiled code directly from your normal VBA project using dedicated functions.
It's like having several modules, except that some modules are compiled into bytecode and thus secure.
No need to learn a new language C or C++ or VB, nor COM add-ins.
Plus, XLS Padlock can wrap your Excel workbook into a secure shell application, which you can then distribute and even sell to your customers.
It does not create DLL files that must then be distributed among your workbook files (imagine if your other non-tech users lose the DLL or don't know what it is), the software compiles spreadsheets + compiled code into a single EXE file.
It is even possible to add licensing features, online activation if you want to sell your workbooks or control who uses them, while keepking your VBA code secret.
I'm doing a gig where there is a need to write a few simple VBA macros for Word and Excel. This is a skill I haven't used in about 8 years -- and things have changed! Aside from the little detail that VBA is clearly in legacy mode, with minimal support, there's all the new security measures designed to close VBA as a malware vector.
Most of this can be worked around with a little effort. But here's a biggie: on some machines (not all for various reasons), the IT people have disabled VBA's ability to reference external libraries. If you give a user a VBA application that uses the MS scripting runtime (handy regular-expression API) or the automation library for another application (for controlling Word from Excel) they just don't work. If you open the VBA IDE on the user's machine, Tools/References is grayed out.
I could work with the IT people to re-enable library references, but there are also external users who might have this limitation. So I need a way to bypass it.
If I buy a certificate and sign the macros, will this give me back references? I can get them to spend the money, but I'm not going to do it unless I'm convinced it will solve the problem.
Can you use late binding?
I built an excel model used to analyze real estate transactions. I would like to create a user interface to overlay the model so that the file can be distributed to clients to evaluate potential investments
The interface will serve two primary functions:
1)Enhance the user experience by creating an easy to follow input page. The entered data will then flow through to the model from which reports will be generated for the user to view.
2)Protect the intellectual property of the model by restricting the user from the underlying model. The user will not be able to view or edit the formulas in the excel file.
I believe this can be done using MS Acess/Visual Basics but I was hoping to find a program that is more professional looking. Can anyone suggest a program/programming language in which this type of user interface could be created?
Thank you in advance for your help.
You don't have to use Access, VBA (Visual Basic For Applications) is built right into Excel. There are good books available and lots of web resources. Your main problem seems to be the UI is not professional - I'd disagree, out of the box it will look like an application developed 5-10 years ago, but it will still work and look ok.
If you want a really slick interface, I'd suggest you look at WPF and integrating that into Excel. However there is a big learning curve to get that going, I'd get a basic UI going, show/sell that to your customers, and then ask them what they want.
I think my first question would be how savvy are you with development? You really didn't elude to that in your post.
If your using Excel 2007, there are ways to hide menu commands in Excel and remove a lot of the current interface and replace it with your own. It looks like Excel and functions like Excel, however, the ribbon interface looks vastly different. The other side is just to add a Tab or Menu and have your commands there. It sounds like you want use Excel as your UI, but replace the commands with your functions.
If you want to HIDE your IP, and you decide VBA is the way to go, then your code is stored inside the Excel Spreadsheet and is accessible to anyone who knows how to open the VBA editor.
If you decide to do it in .NET, then your functionality exists in an assembly outside Excel, and the .NET runtime loads it when you open the Spreadsheet. No amount of poking around inside Excel will help them find your "code".
There are lots of code samples to help you with both. I would recommend VB.NET if you decide to do .NET. From a pure syntax point, VB.NET handles lots of the office programming "quirks" well and can help you speed development. Here is the office development site, that you can go and get information before making a decision.
Also, according to this article you need to buy Visual Studio Professional 2008 or 2005 to get the graphical designers and such. If this isn't feasible or affordable, VBA might not be a bad idea to start with.
In regards to my development savvy, I am novice. I am familiar with the basics of VB but doing the actual development for the type of UI I have in mind is beyond ability. I plan to hire a developer to create the UI but before I can do that I need to decide the language it will be built in.
MrTelly, Chris, I appreciate your advice.
I am currently in the search for a skilled developer willing to collaborate to determine the best language to build the UI and then execute the development. If you have any recommendations or would like to discuss the project yourself I can be contacted at phtwright#gmail.com .
I have an old Excel 4 macro that I use to run monthly invoices. It is about 3000 lines and has many Excel 5 Dialog Box sheets (for dialog boxes). I would like to know what the easiest way would be to change it into VBA and if it is worth it. Also, if once I have converted it to VBA, how to create a standalone application out of it?
I have attempted this before and in the end you do need to rewrite it as Biri has said.
I did quite a bit of this work when our company was upgrading from Windows NT to Windows XP. I often found that it is easier not to look at the old code at all and start again from scratch. You can spend so much time trying to work out what the Excel 4 did especially around the "strange" dialog box notation. In the end if you know what the inputs are and the outputs then it often more time effective and cleaner to rewrite.
Whether to use VBA or not is in some ways another question but VBA is rather powerful and extensible so although I would rather use other tools like .NET in many circumstances it works well and is easy to deploy.
In terms of is it worth it? If you could say that you were never ever going to need to change your Excel 4 macro again then maybe not. But in Business there is always something that changes eg tax rates, especially end of year things. Given how hard it is to find somone to support Excel 4 and even find documentation on it I would say it is risky not to move to VBA but that is something to balance up.
(Disclaimer: I develop the Excel-DNA library)
Instead of moving the macro to VBA, which uses a COM automation object model that differs from the Excel macro language, rather move it to VB.NET (or C#) running with the Excel-DNA library.
Excel-DNA allows you to use the C API, which mirrors the macro language very closely. For every macro command, like your dialogs, there is a C API function that takes the same parameters. For example, the equivalent of DIALOG.BOX would be xlfDialogBox - there is some discussion and example in this thread: http://groups.google.com/group/exceldna/browse_thread/thread/53a8253269fdf0a5.
One big advantage of this move is that you can then gradually change parts of your code to use the COM automation interface - Excel-DNA allows you to mix and match the COM interfaces and C API.
AFAIK there is no possibility to somehow convert it. You have to basically rewrite in in VBA.
If you have converted to VBA, you cannot run as a standalone application. As VBA states Visual Basic for Application, it is living inside an application (Word, Excel, Scala, whatever).
You have to learn a standard language (not a macro-language) to create standalone applications. But you have to learn much more than the language itself. You have to learn different techniques, for example database handling instead of Excel sheet handling, printing instead of Excel printing, and so on. So basically you will lose a lot of function which is evident if you use Excel.
Here is a good artikel about this topic: http://msdn.microsoft.com/en-us/library/aa192490.aspx
You can download VB2008-Express for free at: http://www.microsoft.com/express/default.aspx