I have been using Microsoft Excel 2003 since it first came out and am only just coming across an apparent problem with it. I have a number of .xlt files that are used throughout the company and have never had any issues with them. However, it has just come to light that there is a user who can change the template.
Ordinarily you open the Template file (e.g. Template.xlt) and on opening it find it is called Template1. On pressing the save icon you are taken to the the Save As screen with the default option to save the file as Template1.xls in MyDocuments (Default location).
In this one case though, the user opens the file as Template, and on pressing the save icon overwrites the original .xlt file. I have never seen this before and am bamboozled. Any ideas please?
How exactly does the user open the template?
If a template is opened by double clicking the .xlt (or .xltx/.xltm) file in Windows Explorer, the template generates a new Excel file based on the template.
If an .xlt (or .xltx/.xltm) is right-clicked in Windows Explorer and then the "Open" command is selected in the context menu, then the template file itself will be opened.
If an .xlt (or .xltx/.xltm) template file is opened via Excel's File > Open dialog, the template file itself is opened.
A shortcut that leads to an Excel template behaves in this way:
double-click - creates a new file based on the template.
right-click > New - creates a new file based on the template.
right-click > Open - opens the template itself.
Edit: if the behaviour of double clicking a template file (or a link to a template) occurs only for one user, you may want to unregister and re-register Excel 2003.
Quoting from this question at the Microsoft Answers forum:
> Start>Run>excel /unregserver
> - note the space between excel and /unregserver then
> Start>Run>excel /regserver
> - again note the space between excel and /regserver
I know it's not the best form to answer your own questions, but hopefully someone else will be able to benefit from the solution that I have found.
In order to solve this, download and install a program named FileTypesMan.
Run the program and find the .xlt extension. In an ordinary working system this will have at least New and Open as options with New set to default. In this case there was only Open as an option. Create an option for New and set this to default.....Presto, sorted.
Related
I am trying to change my Excel VBA project name but everytime I do this it always reverts back to the 'default' name of VBAProject.
So far I have tried renaming the project via the Properties Window and by Tools > VBA Project Properties - both times I saved the document but after closing and opening again, the name has defaulted back to VBAProject.
I have full access rights to this document and it is not ready only. I have Trust Access to VBA Project enabled.
What else could prevent me from doing this? I would have at least expected an error telling me I could not do this rather than lead me to believe this is possible!!
I was able to get the project name change to "stick" by clicking on Run - Design Mode before making the change. I clicked on Run - Design Mode a second time, saved the file. When I reopened, the name had still been changed. This is in Excel 2016 VBA Editor.
I have created a simple VSTO project based on a Binary Excel file, the name of the file is Text.xlsb. When I run this in debug mode from VS, the file gets renamed as Test1.xlsb and opens, also my open even is not getting fired, but the Activate event if triggered.
Can some one help me to resolve this? I think VSTO is treating the Excel file as a template and assigning a different name on open.
I am trying to develop an Excel add-in by using JavaScript API for Excel.
I can already make some samples run, launch debugging under Visual Studio. Every time when i launch debugging, it opens a new workbook of Excel.
However, most of time, I need to debug an add-in on an existing workbook. For instance, here is an add-in sample, which opens a blank workbook and adds blank sheets to it. However, I want it to add blank sheets to an existing (opened) workbook. Does anyone know what I should set to debug it on an existing (opened) workbook? Should I modify some lines of code?
Edit 1:
From http://dev.office.com/docs/add-ins/get-started/create-and-debug-office-add-ins-in-visual-studio
To use an existing document to debug the add-in
In Solution Explorer, choose the add-in project folder.
Note Choose the add-in project and not the web application project.
On the Project menu, choose Add Existing Item.
In the Add Existing Item dialog box, locate and select the document
that you want to add.
Choose the Add button to add the document to your project.
In Solution Explorer, open the shortcut menu for the project, and
then choose Properties.
The property pages for the project appear.
In the Start Document list, choose the document that you added to the
project, and then choose the OK button to close the property pages.
Here is the resulting configuration that you should see:
After that just press F5 (start debugging), and you should be good to go.
~ Michael Zlatkovsky, developer on Office Extensibility team, MSFT
For anyone else running into this same issue (i.e. tying to set up an existing worksheet for debugging) without having to jump through 3 hoops to insert the add-in every time, this worked for me:
Set the Start Document to "New Excel/Word/etc Document"
Hit F5 to start debugging.
The resulting new document will be read-only and it will be in the Debug/Release folder.
Close the document, don't save it.
Copy the document to the folder where your Web Add-In manifest is and renamed it to whatever name you prefer.
Uncheck "Read Only" int the file's properties.
Set the Start Document as described by Michael in his response above.
If you start debug now, the add-in "should" load automatically. If you start without debugging (Ctrl + F5), you should be able to close the document and open it (or a copy of it) from anywhere in the PC and it should load automatically. You can even make changes to your JS code and reload the taskpanes/dialogs and it should take effect.
What did NOT work:
Using a blank start document and saving it after inserting the add-in. Once you save it, it loses its connection to the developer add-in.
If you start any document in debug mode and save it, it will NOT work the next time! If you want to make any changes to it, DO NOT start in debug mode.
I am not sure if any of these quirks are by design or if a Windows/Office update messed it up for me. Regardless, this is a very painful experience compared to developing VSTOs.
I came into work this morning and one of my Xpages applications appears to be corrupt. Some design elements are duplicated, and when I open up cc or Xpage design elements I get
"Could not open the editor: Could not parse the .xsp-config file named CustomControls/layout.xsp-config in the project C:\Program Files (x86)\IBM\Notes\Data\workspace\KC1_2fScoular\ComputerTips.nsf."
I am not using source control; I have seen a few people comment that Git can cause this problem.
How can I repair the database??
I've had that happen before in older versions of Domino Designer. Sometimes closing Designer and restarting solves the problem.
The .xsp-config file can be found in Package Explorer and holds the information to display the custom control in the Controls Palette as well as any custom properties. It can be opened directly from there and opens in the XML editor. In a worst case scenario, you can always delete the properties or other XML entities, then paste back in once it's working again (or add the properties back in using the Properties pane). The .xsp file (the underlying Custom Control) can also be opened in the XML Editor by right-clicking in the Package Explorer and selecting Open With and choosing the XML Editor.
Because of the underlying Eclipse functionality, you can delete an XML-based component - XPage, Custom Control, xsp-config - create a new entry with the same name, and use Compare With > Local History to see previous versions. Local History is stored based on the text file name. So you have a (short-term) back, even without source control.
I've writen an Excel-based, database reporting tool. Currentely, all the VBA code is associated with a single XLS file. The user generates the report by clicking a button on the toolbar. Unfortunately, unless the user has saved the file under another file name, all the reported data gets wiped-out.
When I have created similar tools in Word, I can put all the code in a template (.dot) file and call it from there. If I put the template file in the Office startup folder, it will launch everytime I start Word. Is there a similar way, to package and distribute my code in Excel? I've tried using Add-ins, but I didn't find a way to call the code from the application window.
Simply move your code into an Excel Addin (XLA) - this gets loaded at startup (assuming it's in the %AppData%\Microsoft\Excel\XLSTART folder) but if it's a addin, not a workbook, then only your macros and defined startup functions will be loaded.
If the functions depend on a spreadsheet itself, then you might want to use a combination of templates and addins.
I'm distributing part of an application like this, we have addins for Word, Excel and Powerpoint (XLA, PPA, DOT) and also Office 2007 'ribbon' versions (DOTM, XLAM and PPAM)
The addin startup code creates toolbar buttons if they're not found, this means in any workbook/document/etc they can simply hit the toolbar button to run our code (we have two action buttons and one button that displays a settings dialog)
Templates aren't really the way to go for VBA code, Addins are definitely the way to go...
So to load the toolbars on startup we're using something like.. (checking to see if toolbar exists though - code will run for each worksheet that is opened, but toolbars are persistent for the user session)
Public Sub Workbook_Open()
' startup code / add toolbar / load saved settings, etc.
End Sub
hope that helps :)
I always use an Add-in(xla)/Template(xlt) combination. Your add-in creates the menu (or other UI entry points) and loads templates as needed. It also write data that you want to persist to a database (Access, SQLServer, text file, or even an xls file).
The first rule is to keep your code separate from your data. Then, if you later have bug fixes or other code changes, you can send a new add-in and all of their templates and databases aren't affected.
You can modify the user's personal.xls file, stored in the excel startup directory (varies between Office versions). If you have lots of users though, that can be fiddly.
An alternative way to get over your problem is to store the macro in a template (.xlt) file. Then when the users opens it they can't save it back over the original file, but have to specify a new filename to save it as. The disadvantage of this method is that you then get multiple copies of your original code all over the place with each saved file. If you modify the original .xlt and someone reruns the old macro in a previously-saved .xls file then things can get out of step.
Have you looked into ClickOnce deploying the Excel file?
What about to save an excel to network folder with read only permissions ? The authentication can be done with integrated windows authentication and you don't need to store connection password to the database in the VBA. Then you only need distribute a link to this location to your users only once. If you will do an update, you only change data in that folder without user notice.