I have a very old VBA file that was created by someone else with limited comments to explain it. The file is a training file that asks for names, and then supplies the file names you can view to train in. Variables are passed around from 5 different subroutines.
RetVal = Shell("C:\Program Files\Microsoft Office\OFFICE11\PPTVIEW.EXE " & ProgFile, 1)
This is the line that opens the PowerPoint 4.0 files from Excel. ProgFile being a passed variable.
My Problem: If I put the files in directory on the C:\ drive (Say C:\Training\Forklift.ppt) the file opens fine and the program does what it is supposed to do.
HOWEVER: Putting those same PPT files on my network Drive (S:\Training\Forklift.ppt) I get three error messages as pop-ups NOT coded into the program (I suspect System errors). (Path names were changed to show as S:\
PowerPoint Viewer Cannot find the File RECORDS
PowerPoint Viewer Cannot find the File Safety
PowerPoint Viewer Cannot find the File Forklift.ppt
RECORDS and Safety are NOT files being used by any of the subroutines. Is it because of the Shell Function to open PowerPoint or some other mystical thing I am overlooking?
I am trying to rewrite the Subroutines and this is part of the unchanged code that is giving me issues.
try surrounding your arg in quotes:
RetVal = Shell("C:\Program Files\Microsoft Office\OFFICE11\PPTVIEW.EXE " & Chr(34) & ProgFile & Chr(34), 1)
My guess is that RECORDS and Safety are both some sort of external files that are linked in your Forklift.ppt presentation. PowerPoint is notorious for breaking presentations when things get moved. If there are any links in the PPT, they will need to be updated to point to the new location on your S: drive.
You can automate changing the links by writing some VBA code for it, but if this is a one-time move, it's probably not worth it - just redo them by hand.
Related
Recently a large number of security updates were pushed for Microsoft Office at work. We have an Excel tool with a Visual Basic backbone which worked prior to the updates, and now does not work.
I have done some isolated testing and have found that we see the same 'error 75' when using the FileCopy method on .BAT and .EXE files. Other less 'risky' file types seem to be ok. This is also an issue with the 'Open' command.
Does anybody know of a workaround for this issue when copy/pasting .EXE and .BAT files, or maybe this is a known issue with a certain security update? I have searched everywhere, but the Google is failing me. I am hoping either:
Someone knows which security update is the culprit and I can try
uninstalling it to see if that fixes the issue
There is a different way to copy/open/manipulate .BAT and .EXE files that doesn't violate the new security patch.
Some background:
We are using Microsoft Office Professional Plus 2010 and the tool uses Excel as the interface.
Here is the testing code I am using. I have verified that .TXT and .DAT files run just fine while .EXE and .BAT files cause 'error 75' indicating a permissions error. And before you ask, yes, the file path is correct, I have just omitted my employee identification information.
Sub Macro1()
' Declare variables
Dim Filename, SourcePath, DestPath As String
' Pathname variables
Filename = "test.dat"
SourcePath = "C:\Users\<REDACTED>\Desktop\working_copy\" & Filename
DestPath = "C:\Users\<REDACTED>\Desktop\working_copy\test\" & Filename
' Copy file from Source and paste in Destination
FileCopy SourcePath, DestPath
End Sub
Here is an image with the updates that were installed. The tool worked prior to the 6/14/2017 dump, so anything before can be disregarded.
Sorry for the image, too many to enter them manually, no easy way to copy from the update list:
MS Office 2010 Security Updates
Nothing with the tool or file structure changed. The only thing different is the updates. Also, we tested the same tool with Microsoft Office Home 2016 and it worked without a hitch.
Any and all help will be appreciated. Thanks in advance!
While I never found a real fix for this issue, I did come up with a slightly 'hacky' work-around.
The MS security patch prevented me from copy/pasting .BAT and .EXE files, I but could still save .BAT files.
So, I ended up having my script create a text file called "copyExe.txt" which had a single line:
ECHO F|xcopy <source> <destination>
This was then renamed to be "copyExe.bat" and run.
By creating a .txt file, I circumvented the errors when using the VBA Open function on .BAT files (so I could actually create this new batch file). This batch file has the sole purpose of copy/pasting a .EXE file from one folder to another, which circumvented errors when trying to copy/paste .EXE files.
After the copy/paste script is run, it is deleted.
All-in-all it feels like a very silly solution, but it works and is very non-invasive for the user.
I'm trying to get some data out of excel files. Never used excel before but I understand VB. So I have a file with a button my boss implemented as well as his code he used. Here is the code:
(you can see the "Get Data" button in there)
My exact problem is that I don't know a lot about excel so if someone could help me figure out what is going on as well as figuring out how to correctly use directories that would be awesome! For more context when you click the button it gets all files in the directory and then the user clicks a file then excel follows a macro to get some data out of sed file.
Right now it returns nothing but there is 5 files in that directory?
Here is what the default directory looks like after edit:
And here is the files in my directory:
As #Tim Williams says ... Insert the back slash after the folder name
DirNow = Dir(Range("DefaultDirectory") + "\WFP*", vbDirectory)
EDIT
Basic troublseshooting
Does it it compile?
Looks like "UserFormDataa" - should maybe be "UserFormData"
Add Debug.Print DirNow after it's set and show us the display
If that's not right add line
Debug.Print Range("DefaultDirectory") to makes sure range is defined properly
Remove vbDirectory - unless you're going to handle processing files under the matching sub-folders
You are missing the terminal backslash on your default directory.
C:\Users\CUCCOMTT\Desktop\Excel Project\
Otherwise you're looking for files named
C:\Users\CUCCOMTT\Desktop\Excel ProjectWFP
I have an Excel sheet with an embedded txt file which I would like to copy into a certain target folder.
I used the following code which works fine if I use it from my computer:
'copy oleobject
ActiveSheet.OLEObjects(1).Copy
'paste to activeworkbook's path
CreateObject("Shell.Application") _
.Namespace(ActiveWorkbook.path) _
.Self.InvokeVerb "Paste"
However, some of my colleagues did receive the text file which was embedded in the Excel sheet with an additional line beforehand which included the file save path in the temporary folder.
I could just delete this line with VBA but I would like to understand why this happens with other computers and not with mine.
Please help!
Thanks
OK so here is the issue:
txt file is a template and VBA is supposed to read it in again in a string file and change it. Until now it was just saved in a different folder and that worked fine but for mobility reasons (to be used by many other users) it would be a great advantage if it could be handled with just one file.
It is possible to do this with txt file embedded in Excel, but embedded files are not really well-supported by VBA automation. Most files only have a few methods available, and if I remember correctly with TXT file type, the available method is to open the file.
ActiveSheet.OLEObjects(1).OLEFormat.DoVerb 1
I mentioned a similar problem that I had (in PPT, instead of Excel, but the issue is the same). The route we chose initially was given here:
Extracting an OLEObject (XML Document) from PowerPoint VBA
Invoke the .OLEFormat.DoVerb 1 to open the file in Notepad
Use WinAPI functions to read the contents of Notepad into a string
variable
Use WinAPI functions to close Notepad
Use FileSystemObject to write/modify a new text file
Embed the new, modified text file
The functions to find and read Notepad contents are documented here and require some use of WinAPI functions (all noted in the link):
http://www.excelforum.com/excel-programming-vba-macros/729730-access-another-unsaved-excel-instance-and-unsaved-notepad-text.html
This is a LOT of work for not much benefit, instead you could simply open a file dialog prompting user to choose the text file (located on a shared network drive, etc.). This would be much more reliable.
Alternatively, depending on the size of the text file, you can store the contents inside a Shape (and you can put the shape on a hidden worksheet, etc.), either in the .TextFrame or another property that allows text. Ultimately we abandoned the solution in the links above in favor of storing the contents inside a Shape's .AlternativeText property. This worked very well for us, in storing XML contents of about 500,000 to 1 million characters per file.
The reason we chose not to go the Notepad route is that there was a lag while the file is being read and user could accidentally interrupt the procedure, corrupting the file(s), etc. and that Notepad doesn't fully support automation, etc.
I also thought of using a text field but if the oleoobject would work I thought I could also embed other file types like pictures.
Pictures are easy to work with because they have a built-in .Export method.
I'm looking for a way to have Excel files in my Matlab folder open 'outside Matlab' (i.e., by MS Excel in most cases) directly by double-clicking the file, rather than right-clicking and selecting 'Open Outside Matlab'.
The .xls files reader built in Matlab can be terribly slow for large files, and an unwanted double-click on a file can cost quite some time in which Matlab is unresponsive.
Thanks.
When you click something in the Current Folder tab, it's actually running the open command, which itself calls finfo to determine what it means by "open" for a given extension. You can see this by creating a breakpoint in open.m directly after the line [~, openAction] = finfo(fullpath); and double clicking - when it hits the breakpoint you'll see it returns openAction as uiimport.
In theory, you can create custom methods for extensions by creating on the path a function openabc where abc is the extension, which should be returned as the openAction.
However, if I look at my finfo.m it first searches for said functions and then regardless of whether or not it finds them if there is an inbuilt method it overwrites them with the standard behaviour. There's even a comment:
% this setup will not allow users to override the default EXTread behavior
If you are willing to muck about in the inbuilts, you may be able to do it like this (backup first! - this could affect other things). I did it temporarily by shadowing the existing finfo like this:
edit finfo.m (Now save a copy to the current folder)
Add these lines after the loop that defines the openAction (in my version, around line 85):
if any(strcmp(['.' ext], matlab.io.internal.xlsreadSupportedExtensions))
openAction = 'winopen';
end
From the folder containing your edited finfo.m, type which finfo -all. You should see two copies, the MATLAB one labelled as shadowed. Opening something from the current folder window should now open Excel externally.
I don't believe there's any straightforward way to do that. It's built in to MATLAB that Excel files will open in the import tool when you double click on them, and there's no way to change that.
You might be able to get around it by changing the file extension on your Excel files to something other than .xls or .xlsx. That would stop MATLAB from opening it in the import tool. Then in Windows, you could associate the new file extension with Excel.
I've just upgraded to Excel 2010 from 2003. An internal add-in that is heavily used uses the Application.GetSaveAsFilename method to prompt for file names to be used for an export process (exporting information from the current Excel file into an xml configuration file).
In 2003, even if they selected a Read Only file, I didn't get any prompts (which is what I want) leaving it up to me to handle read-only issues (which I do...e.g. I check the file out of source control). However, after upgrading to 2010, I can't select a filename if that file exists and is readonly, forcing me to manually go checkout files first (which is a major downer in terms of proficiency when I'm exporting ~60 files per day).
Does anyone know of any settings/workarounds so that Excel 2010 doesn't prevent (or even prompt hopefully) selecting a filename of a previously existing/readonly file?
Thanks in advance.
Does it help if you use Application.GetOpenFilename instead?
Sub PromptForFilename()
ret = Application.GetOpenFilename
MsgBox ret
End Sub
This doesn't give me any errors for a read-only file.