I've built a simple Excel tool that uses the additional Calendar Control(mscal.ocx). Everything worked out fine, on different systems, however, the calendar seems not to be implemented and instead of just not showing the date picker, the whole form crashes.
Is there a way to implement the calendar control so that it runs on every system? Or do I have to code a datepicker myself?
(Office12)
Whenever you're using controls that aren't native to all operating systems and versions of excel, you're asking for trouble on other computers. Often, when developing, you'll have access to forms that don't exist on most systems, and only exist on yours because you have Visual Studio installed, or a special Microsoft Office package. Whenever such a problem occurs you have 3 choices:
Work your ass of to try and package the missing controls (mscal.ocx), and try to create a deployment script for your users which will copy it to the System32 directory and register it. This is a pain because there is usually a large chain of dependencies for a single control.
Deal with the fact that some systems won't support your tool and warn users upfront or provide a virtual machine that they can access that and that your tool will run on.
Reinvent whatever fancy control you're using with basic buttons, list-boxes, drop-downs, images, etc, which is the biggest pain of all and often requires you to compromise some nice functionality.
I've had to do number 3 countless times for excel 2007 tools that work on XP systems, but not Vista+ where certain ActiveX controls (i.e. Datagrid) are no longer supported.
i would build against Excel 10 (2003) as not everyone might have new Office 12 (2010).
or see if you can reference that ocx locally and deploy with your excel file
You can do this without the calendar controls.
Like this example here
Related
This is hardly the first time this question has been asked, but there are no completely satisfactory answers that have been presented, and nearly ALL of them rely upon Microsoft's error-laden developer documentation.
After creating a vb.net VSTO Excel Template project using Visual Studio 2019 with Office 2016 and porting exiting VBA code to vb.net, I have run into a brick wall. I was able to convert the code to vb.net without too much trouble, and thanks to the .net libraries, I was able to include additional functionality that before was impossible with VBA (e.g. Action Panel menus, etc.). But now I cannot distribute the solution to my employees because I cannot create a setup file that will allow the template code to run correctly when the resulting document is saved to any location other than where it was first installed.
I have tried using the supposedly simple ClickOnce method. I have tried the Windows Installer method. We don't have a Sharepoint server (we are a small company) and I don't want to learn how to create one. I have followed the examples at
https://learn.microsoft.com/en-us/visualstudio/vsto/deploying-an-office-solution-by-using-windows-installer?view=vs-2019
and
https://learn.microsoft.com/en-us/visualstudio/vsto/deploying-an-office-solution-by-using-clickonce?view=vs-2019
and
https://learn.microsoft.com/en-us/visualstudio/vsto/deploying-a-vsto-solution-by-using-windows-installer?view=vs-2019#to-build-the-setup-project
and several other Microsoft Visual Studio VSTO instructional articles to no avail. I still cannot get the resulting template file to reference the necessary libraries when the template is moved or saved to any location on a user's computer other than its original install folder. This pretty much makes the solution useless to me. You would think something this important to so many VBA users would be a priority to Microsoft, but it clearly is not. Microsoft refuses to fix/update its documentation, and it ignores vb.net like Microsoft's own policies had nothing to do with why so many of us use it.
I would post my code, but I have no idea what code, in what has now become a rather complicated solution, is causing the problem. My only clue is the error message, which appears whenever the Excel workbook is saved somewhere else and states that "my solution".vsto could not be downloaded because Office is looking under where the template is now stored rather than the original installation directory.
We have a small MS Access database shared between staff in an office. Recently the company upgraded my computer to Windows 10 and Office 365. Now when I use the database, it sometimes causes it to fail for other users who are using Windows 7 and Office 2013. I didn't make any changes to the database structure or programming or anything.
When the other users try to open the database after I have used it, some of the symptoms they are seeing are: a small flickering window that appears when they first open it, having to click twice in a text box in a form to get the cursor to appear, and having the database crash (gives an error message and opens the VBA window) when trying an operation that involves VBA code.
Do you know what might be going on? Is this a known issue? Is there any good way to fix it (other than getting everyone on the same operating system or maybe splitting the database, which I don't really want to try)? (I tried reverting to a back-up of the database, which fixed the problem until I entered more data into one of the tables, then the problem came back again.)
You really should not have simultaneous users with different Windows/Office versions working on the same front-end.
Access only stores a single copy of compiled code, with references to at least its own libraries. This copy is only compatible with the same major version of Access.
If you have two different versions of Access working on the same file, the code will need to be recompiled constantly, causing delays, possible weird behaviour, and possible VB Project corruption.
Split the database, and make sure front-ends are not shared between different versions of any of the DLLs Access is referencing (or, ideally, not shared at all). Different versions of Office is a common culprit, different Windows versions matter less often.
Is you Access file using any other Office functionality (Word, Excel, Outlook)? If it does, when you open it in Office 365 it links to the references for the newer versions of these products breaking the references for anyone that has the older versions.
The only way around that is to split the database and have different front ends for each version of Access. They can still share the same data (back-end).
Splitting the database is not really complicated. Just make two copies of the database. On one (front end) delete all tables and queries and then link them from the other one (back end). You will have some redundancy that can be cleaned up later in your back end (for example all forms/reports can be deleted form the back end), but other than that is all there is.
So i have this typical problem of distributing an Access application to a client. The application is written in Access 2010 and recently i addded some code to export Excel sheets. Therefore i added the excel object library version 14.0.
My clients that run Excel 2007 cannot run the application anymore getting the infamous error: "mssing or broken reference to the file excel exe version 1.7". The question is this:
If i use LateBinding, will the added functionality be available to them ?
I wish to apologise if the question sounds naive but i am new to VBA.
Yes, the functionality should be available, UNLESS you use features that were not available in 2007 (Some table theme formatting using patterns for example is 2010plus) then you should have no issues using late binding.
I guess the easiest is to simply try. Ideal would be to have a virtual PC running Office 2007 and develop using that, when you are targeting client using a lower version than yourself.
Hope that helps.
I've created a library to pass/get data to/from excel.
To execute in my machine i modified the access permisions in COM+ console.
The thing is that im interested in upload this component to my online server, but there i havent installed excel.
Are there any way to register excel in COM+ without install excel?
Thanks in advance.
Best Regards.
Jose
If your library uses Office Interops to manipulate Excel, then no you can't register Excel in COM+ without installing Excel, since there would be nothing to register against, or interop for that matter.
Even if you use late binding in your code, so that it compiles, you will experience runtime errors if the Excel components are not installed.
"All current versions of Microsoft Office were designed, tested, and configured to run as end-user products on a client workstation. They assume an interactive desktop and user profile. They do not provide the level of reentrancy or security that is necessary to meet the needs of server-side components that are designed to run unattended." - http://support.microsoft.com/kb/257757
with the push to leverage visual studio and dotnet with office based solutions, especially excel, where is the best article or information on how having office sheet with additional binaries and assemblies is sharable.
Do this external code get packaged with the spreadsheet
what if people start emailing the spreadsheet around. Is there any overhead of this additional assemblies. Is there risk of the binaries getting detached from the spreadsheet
It seems like microsoft has been pushing VSTO for over 5 years now but you read lots of mixed reviews and issues. Are we at the point where companies that do large VBA excel solutions can fully migrate over to dotnet without any real worries?
First of all, I want to answer your question on whether or not VSTO is ready for larger implementations. The answer is YES! Especially if the alternative is VBA. You have the entire .Net framework available, you can use web services, ADO.Net (better still, with the enterprise library). You can still write code that looks a lot like VBA, but is much more powerful. You can get more information by reading Walkthrough: Creating Your First Document-Level Customization for Excel. This page will give you an idea of what VSTO features are available to you.
Now, to answer your question on deployment.
It depends on whether you are making an Add-In or a document level customization. If its an Add-In, then you must install it on each client, and any passing around of documents will not effect that (Add-Ins are at the application level, and not at the individual document level).
I assume that you are talking about a document level customization, so I will center my answer around that.
When you create a document level customization, the assemblies are not loaded into the excel file (as they are with VBA). Instead, a document property is added telling the application that this document contains a manifest file (and tells it of the manifest file's location). The manifest file contains links to the assembly that makes up your customization.
As with any .Net application, there are sometimes other (referenced) assemblies that also need to be deployed. Not always are these assemblies in the GAC, so they would have to be located in the same folder as your executing assembly (in this case, your customization assembly). You don't necessarily have to place your assemblies in the same location as your excel file, though.
There are a few ways you can deploy the customization.
You can store all of the assemblies and the excel file in a folder and run the application that way (if the excel file is passed around, the users must pass around the entire folder).
You can run an setup program that installs the assemblies to a specific folder on the users computer, and specifies the manifest at that location (if the excel file is passed around, the users must also pass around the setup program).
You can install the assemblies in a network location and specify in the document properties, that the manifest and the assemblies are all at that network location (if the excel file is passed around, nothing needs to be passed along with it - but there are security settings that need to be made. Read this page for more information).
Any way that you decide to do this, here is the page you need to read in order to understand the document properties that enable the customization.
You need to make sure all of your users have the prerequisites installed. The easiest way to do this is to give them all a setup program. If you create a setup project for your customization, you can setup the bootstrapper to automatically install the prerequisites. You can also do this if you use ClickOnce to install the customization. This page will give you all the information you need to know regarding deployment.
Here are some other helpful links you will need to see:
Application Manifests for Office Solutions (2007 System)
Deployment Manifests for Office Solutions (2007 System)
Application and Deployment Manifests in Office Solutions
I hope this helps. Once you read all of this information, I think you'll agree that VSTO is a much better choice than VBA. You just have to plan your deployment carefully.
I created a Excel add-on and deployed it to a server. Then I passed around two links, the setup.exe file and the link to the actual Workbook. The workbook file never changed - it's purpose was to open and load the add-on which was now in the user's Add/Remove Programs. The add-on itself would check for updates on startup.
So if they start emailing the workbook around, great! I believe in theory, the workbook would download the add-on if it was missing, but I don't have a fresh computer around to test that. If it doesn't, it's just a simply exe to install (which will update on launch anyhow, so outdated isn't an issue).
For document-level deployment, I recommend the following three links:
https://msdn.microsoft.com/en-us/library/ms268758(v=vs.90).aspx
https://msdn.microsoft.com/en-us/library/ff937654.aspx
How do you assign the Assembly Location of an Excel VSTO Installation?
Unlike application-level solution, document-level has 2 special properties: _AssemblyLocation and_AssemblyName, which indicate the *.vsto position. To set these properties by install path, a custom action project should be created to record the target path when installing, and packaged together with setup.exe. Then you could put your excel file anywhere (on local machine) and open it in the correct way.