Having a few issues when opening an external excel file.
Basically we have a system where we use a template excel file that writes to another excel workbook. (Multiple users could be in a template file at any one time)
The code is pretty straight forward in that it opens the file as readonly when extracting information and it opens the file as normal when adding/updating new information.
An issue has arose though with 1 particular user - when they click the button to update it always opens the file as read only (doesn't happen to anyone else) I have tried putting her on a different PC and it worked fine - so I am thinking it must be something to do with her settings on our system.
As anyone else come across this or any ideas how to resolve? (Done a office repair but didn't help)
Thanks
Related
I am running Excel version 16.45 on Mac.
I have created a .iqy and saved it in the Queries directory alongside certain templates which were already there.
I go to Data/Get External Data/Run Web Queries. While the templates are accessible, my file is visible but greyed out (same thing happens if I save the file in a different directory).
Would anyone be able to help?
According to your information, I would like to confirm whether the issue occurs when you follow the steps as below:
1.Create a Word file, paste the web URL.
2.Save the Word as .iqy with .txt format.
3.Choose MS-DOS as coding.
4.Create an Excel file and click "Data >Get External Data >Run Web Query (Or Run Saved Query) " of the Bar
I was able to address the issue as follows.
When navigating to the relevant directory with Finder, the '.iqy' file appears to be appropriately named (as per Image 1).
In fact, if you reach the file in Terminal, the file is saved as '.iqy.txt'.
So all I had to do is rename the file, simply removing the '.txt' string at the end.
Screen you see when navigating in Finder
I have an Excel 2016 file (.xlsm). After few weeks working on this file, now I'm facing with one small but weird problem - cannot open ThisWorkbook module. As you can seen in the picture, trying to open this module, window just simply freezes on the screen, any mouse's single or double-clicks on it have no effect.
Maybe somebody also had the same issue? What might cause it and how to resolve it?
this might have only worked for me but is worth a try
clear the office cache (C:\Users\username\AppData\Local\Microsoft\Office\16.0\OfficeFileCache\0)
open the file on a different computer and name it something random.
open the file on the first computer and resave file.
As pointed out in Han's comment, it's possible that the module is corrupted. You may be able to salvage it by right clicking the module and using 'Export File...' to save it as a class file.
If this succeeds you can attempt to recover your code by:
Importing the saved file, this will add 'ThisWorkbook' as a class file that can be opened like other modules.
If this doesn't work, try opening the saved file in Notepad. This should reveal your code in plain text.
I literally have this probablem every day or so. There is no answer, I have to save multiple files everytime I make any changes to the workbook. Its incredibly frustrating when all the macros disapear from the list and you can't open a single module
I'm using the following the code to open a file that resides elsewhere on the computer:
System.Diagnostics.Process.Start(PathToOpen)
Where PathToOpen is the full address to the file I wish to open. This appears to work as intended for any file type that has an application installed that can open the file.
Whilst this works OK, if the file is on a networked drive, I want my VB.Net code to check if the file is currently in use, if so display a message. Currently what happens is if a second user tries to open the file, it opens read-only (a word file for example) which is handled outside of my application. I want to intercept before the file is opened and stop the process there.
Is this possible at all?
You are basically asking if it's possible to monitor files on a system that doesn't even belong to you ?
Word does know about a file already in use because it creates a hidden file next to the one you open. if there is already a hidden file, it means the file is already in use.
Other applications use different ways of knowing if a file they can use is already opened somewhere else.
In order to do what you want to do, you need to know how all the applications handle this problem...
A possible solution would be for you to create a small hidden file next to the file the user wants to open (just like MS Word does). Only problem, you need to destroy the file when it's closed by the user, and you have no way of knowing that...
Good evening,
I have the following problem to solve:
I want to add to an Excel file the contents of a bunch of user-generated .txt files. These files are generated throughout the day and sent over FTP to a folder, which is being constantly monitored by the program to see if there are new additions.
If the program finds new .txt files in it, it opens the Excel file which is to be edited, adds the info and then closes the Excel, saving the changes.
At the same time, users have to open these Excel files to check the new updated info and deal with it accordingly.
The program's execution is somewhat like this:
Infinite loop checking if the folder is empty or contains new .txt files.
If the folder is not empty (hence there is info to be added), it checks whether the Excel file is open or not.
If the Excel file is closed:
Opens it programmatically and adds the info to it.
Saves the Excel file and quits.
Backups the .txt to another folder in case there was some sort of error.
If the Excel file is open:
Keep checking until it is closed.
To check if the folder is empty or not I use: System.IO.Directory.EnumerateFileSystemEntries(path).Any()
To check if the Excel file is open I use:
System.IO.FileInfo(path) and a FileStream which, inside a Try-Catch clause, opens the FileInfo in the following mode: info.Open(FileMode.Open, FileAccess.ReadWrite, FileShare.None)
For the opening, editing and saving/closing of the Excel file I use Microsoft.Office.Interop.Excel.Application, [..].Workbook and [..].Worksheet.
The main problem comes when a user opens (through the normal Office Application) the Excel file in the middle of the addition process. I was hoping to find some sort of lockage of said file so the user cannot interrupt the editing process.
Any ideas on how to combine both types of opening/editing the Excel file?
Thank you so much in advanced.
TL;DR: How can I prevent, programmatically, a user from opening an Excel file while a program is editing that very Excel? Or at least, open another instance of it so the process is not interrupted?
PS: If any further code should be needed, I'll gladly post it :)
I think you need a better solution. It sounds like you are maxing out the capabilities of Excel. You would be better off, if possible, to use a database.
I'm writing VBA codes for multiple Excel spreadsheets, which will be shared with others from time to time. At some point I find there are lots of duplications in my works. So I want to find a way to share codes in a sort of Excel add-in, like the .xla file.
But when I tried to save the Excel file containing shared codes as .xla file, I got some problems:
The file cannot be edit anymore after I save it in the default add-in folder
If I move the .xls file to a folder other than the add-in folder, and open it directly - I cannot use its classes - which creates problems for sharing the codes
Any ideas to create add-ins in a flexible and powerful way please?
Thanks a lot for the help
Not completely sure this is what you're looking for, but ...
(1) save the .xla/.xlam code by clicking the save icon in the VBA editor. HOWEVER, the thing that saves is the thing currently selected in the Project Explorer pane, which lists all open VB Projects and which is usually on the left. Even if you are staring at your just-edited VBA code, clicking the save icon will not save your code unless it is also selected in the Project Explorer pane. You won't get feedback that anything was saved - but you can verify by checking the file timestamp in a separate window.
(2) if you have an *.xls file which (via the formula bar) refers to VBA functions from your *.xla / *.xlam file, then if you open the *.xls file without opening the .xla,.xlam file first, Excel may create external links to resolve the formulas (i.e. referring to a file which is not open). If you have moved or renamed the *.xla file you can get stuck with those "mangled formulas" and need to edit out the pathname links that Excel inserted using a global substitute. If you arrange to open the .xla,.xlam prior to any *.xls file that uses it, you shouldn't have a problem (e.g. by using the default folder).