There is a network share used as repository in my company and it is quite difficult to navigate through it and find certain files. Some of these files get a new name every day , usually the date changes, which makes it impossible to create shortcuts to them. Usually these are excel or word files. Is there a way I can create a shortcut to that file even though the date has changed on the name of the file?
If you definitely have to use a shortcut (lnk file) for this the only workaround that comes to mind is pointing the shortcut to an environment variable and changing that programatically (wildcards are not supported in lnk files afaik).
However I assume that in most cases what you want is not really a shortcut in its technical definition but rather a way to open the file you want with a double click. In this case it would be a lot easier to just use a simple script that figures out what the name of the file currently is (by whatever rules you use manually) and launch it.
Should be doable in vbscript or powershell (maybe even batch) just fine as long as there is some logical way to determine which file is the right one (e.g. always the current date, always the file where the date is newest, the only file with extension xlsx, ...)
Related
I have folders full of log files, and I'd like to display their final status in a column in the folder they are in. That is, in Details view I want to make a new column that shows a piece of text which is extracted from each file. I don't expect to find such a thing out there, and the searches I've tried haven't even yielded a hint about how I would go about writing a plugin to do any such thing. Is it possible?
This sort of thing used to be possible with custom column handler shell extensions but Microsoft removed support for those in Vista (3rd-party Explorer replacements might still support them).
Microsofts inadequate replacement are property handlers. You cannot do this for .log files, you would have to invent a .myapp-log file extension.
Some people abuse the Windows 10 cloud API to create columns but that only works in specific folders.
If you are looking for a specific string in the last line, you could perhaps use a custom icon handler for .log files.
I want to create generic shortcuts in Windows 10 using a target path
extension of the shell path, something like
%windir%\explorer.exe shell:AppData ..\Local\Temp
%windir%\explorer.exe shell:AppData works by itself, takes me to roaming userfiles.
I could use
%windir%\explorer.exe shell:UsersFilesFolder
which would take me to %UserProfile% and append from there (if I could find out how) only it would be handy to be able to go up a level if possible as well.
I can't work out
How to append a further couple directories into the shortcut target path
How to go up one directory first (..?)
What is the syntax to make this work?
First of all, %Temp% might not be the same as %LOCALAPPDATA%\Temp!
The way to create a perfect shortcut to %Temp% is not that easy, ideally the .lnk should only contain a EXP_SZ_LINK:EXP_SZ_LINK_SIG block with the %Temp% string. You have to manually delete the ItemIdList block to get a .lnk file like that. %Temp% is extra complicated because it does not have a special folder canonical name you can use with the shell: protocol.
I don't believe the shell: protocol supports .. nor . path components.
shell:AppData ..\Local is also wrong because the local appdata folder might be somewhere else (< Windows Vista used different names) and a better command would be %windir%\explorer.exe "shell:LocalAppData" (and in turn %windir%\explorer.exe "shell:Local AppData\Temp") but all of those commands have other issues.
First of all, Explorer might not be the users shell and you risk not obeying the users preferences.
Another problem is that a .lnk file contains the attributes of its target and because the link actually points to a .exe file your .lnk file will not have the FILE_ATTRIBUTE_DIRECTORY bit set for its target attribute and the shell will not understand that it points to a folder. A .lnk that points to a folder will sometimes open in the same window when navigating the shell instead of opening a new file browser window.
The .lnk binary format is documented and by breaking the rules a little bit I have been able to create a link that points to a file/folder inside a special shell folder by combining a EXP_SPECIAL_FOLDER block with a manipulated ItemIdList but for whatever reason this trick does not work for deeper paths.
A EXP_SPECIAL_FOLDER block and a empty ItemIdList is the only way to create shortcuts to special folders that is guaranteed to work on all systems but you have to create it manually, the IShellLink implementation adds system specific blocks that might break things if you try to use the link on another system.
The .lnk format has not changed much since Windows 95 and there is simply no easy way to create shortcuts relative to special folders that also work when they are copied to other systems. The relative path string in a .lnk is relative to the .lnk file itself and is not helpful in this case.
I would recommend that you simply create the .lnk on the target system in your installer/application and let IShellLink fill in as much information as possible behind your back.
I am using Base SAS 9.4 on Windows 7. For various reasons, which are detailed below, some of my programs have extremely long names. Exacerbating this further, the programs are stored deep in the abyss of a network drive. This causes problems when trying to open from Windows Explorer. I believe the problem lies with SAS, but have tagged the question with Windows in case not. I'm hoping there is some way to address this problem via a configuration file or an edit to the registry.
To open a program, I typically double click on the .sas file in Windows Explorer. This opens the Enhanced Editor after a brief waiting period in which a SAS message box states:
The SAS System is processing requests. Please wait...
When a program's full name, including path and extension, exceeds 182 characters (i.e. has form: \\network-location\a\bunch\of\....\folders\program path exceeding 182 char.sas), the same "SAS System is processing requests" message appears, but then a Windows error is generated.
Not surprisingly, no solution is proffered by Windows.
When the program name is such that the full path is exactly 182 characters, nothing happens. I double click on the program and the only result is to select the file in Windows Explorer. If I monitor "Processes" within the Windows Task Manager, no new processes are started when such a program is double clicked.
When the program name is such that the full path is less than 182 characters, the program opens in the Enhanced Editor as expected.
According to MSDN, the max path is 260 characters. Clearly, 182 is well below that limit. SAS is the only application which has a problem with the path length. For example, I can copy the file name and extension, create a new text document with the same name (plus .txt) and open the file in Notepad, Notepad++, Word, Wordpad, Emacs, etc.
I have deduced two workarounds for working with names exceeding 182 characters.
If I open SAS via SAS.exe, I can load a program through the Open dialog with a path exceeding 182 characters just fine. This is not a good solution, however, as the Open dialog does not allow paths to be copy/pasted. The entire file path must be traversed. I can also drag such a program into the editor window within SAS to load it. This too is not a good solution, as a program will only load if there is a blank editor window. If the program is accidentally dragged on the the log window, it will execute automatically. Also, the program does not open in a convenient location. It opens in the middle of the Enhanced Editor and must be manually resized. That the programs can be loaded and executed at all leads me to believe that there is some way to fix this problem. It seems that somewhere in the process of loading the file, SAS violates some variable limit.
Of course, people would suggest that I use a different network location or shorter names. To the former, I am required to use a specific network location. To the latter, these programs are being developed in parallel with various reports. Many of the programs are similar and the corresponding references (table/figure numbers) in the reports change multiple times/aren't always communicated to me. Through experience, I've found the surest way to work with these uncertainties is to simply name the file by the label it's given in the report. Otherwise, I need to adopt unclear abbreviations, bad organizational practices, or introduce intermediate steps (like creating codes or a document which indexes the programs).
Edit: Per Joe's comment, it seems that the Open dialog allows copy and paste for specific file names. A file path can be copied in Windows Explorer via Shift + Right Mouse Click > Copy as Path and pasted into the "File Path" box in the Open dialog.
To avoid traversing the tree, the Current Folder may be updated before accessing the Open dialog. This is located at the bottom right of the Enhanced Editor.
The Open dialog starts at whatever the Current Folder location is set to.
I suspect your issue is that your 260 limit is in fact applicable.
When you double-click a program file, it doesn't just copy the path to SAS. Instead, what happens is SASOACT.exe is called, with a command of something similar to this:
"C:\Program Files\SAS94\SASFoundation\9.4\core\sasexe\sasoact.exe" action=Open datatype=Access filename="%1" progid=SAS.Application.940
That's well over 100 characters already by itself; presumably, behind the scenes, you end up with something like
"C:\Program Files\SAS94\SASFoundation\9.4\core\sasexe\sasoact.exe -open ""%1"""
Which adds around 70 or 80 characters to what you're passing it. Thus the 260 character limit.
You should use one of the workarounds - I personally prefer to just file->open, myself, but really whatever works best for you is fine. You could also consider using another editor for the simple double-click actions, though any editor you chose would still have some issues.
You could also consider asking IT to install SAS itself in a location that had a shorter path name, though realistically that might save 10 characters or so.
As for pasting; you can paste a path name just as easily as a file name into the file->open dialog. I have no idea why you don't seem to think you can, but I just did so now with no more difficulty than any other folder dialog...
Another workaround to consider, by the way, is mapping a drive letter to the network path. I.e., if your network path is
//myserver/projects/financial/projectnumber/.../
You map some letter (let's say R: arbitrarily) to that root path, //myserver/projects/financial/projectnumber, which is not changing anything other than how you refer to it locally. Then you can use:
R:\...\filename.sas
And you don't have to navigate paths, etc. You'd have to repeat that mapping process on any machine that you wanted to do this on, but if this mostly about your own workflow, that shouldn't be an issue. Just don't refer to R: inside the program itself and nobody else will ever know that you've changed anything.
I would like to specify that images of a certain type (for example, .png) open by default in a program I've written when the file is contained in a certain directory. I've seen by searching (Change Default Program for a specific folder) that this is not possible on Windows 7 or 8.
I am saving these images in this directory myself, so I have some leeway with how I name the files. For example, I could change the filename a bit... perhaps to be example.myprog.png or something similar. Is there a way to set it up so files that match this filename pattern get opened, while other .pngs (in other directories) still open in the default viewer?
I don't really want to name these PNG images example.myprog (i.e., fully change the extension), because when the user is browsing the directory in Windows Explorer, I would like the thumbnail images to still show up. Also, users will be eventually transferring these images to their own machines, where they'll want to use standard image viewers to look at them.
If this is not possible, does anyone have another suggestion for how to tackle this problem?
As you are mentioning that files should be opened in a program that you have written, try to change the code of your program to read files from the specific folder. So, by opening your program from anywhere in your pc, you should be able to open files from specified folder.
As I understand it, when a file open dialog box (such as GetOpenFileName) is used, Windows will automatically remember where the last file was that was opened by the program, and Windows remembers these locations separately for each program. Is there a way to directly alter this, in order to cause the file picking dialog for program X to start in C:\Example\Directory?
I'm attempting to automate a program which has been programmed to work only through a GUI, and I don't have any access to the internals of this program (such as being able to alter how it calls the file picker). Instead, I'm using a mouse macro (via AutoHotkey). If I can be completely sure that the file picker will start in a particular place, I should be able to automate the rest with mouse clicks.
If you had access to the source code, I'd suggest you just change the lpstrInitialDir property of the OPENFILENAME passed to GetOpenFileName().
Outside of that, you'll want to change the registry keys for the MRUs:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32
What might make more sense, and might fix the issue you're having, is also changing the Working Directory so that the default location isn't "My Documents", if you're experiencing that.
Depending on the operating system, the results vary:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646839%28v=vs.85%29.aspx