If you look at Classic Shell Start menu, you see that it has a section for recent applications. Every item in the section can contain popup menu, usually used for displaying recent documents, opened earlier in the application. For instance, the 'Word' item contains all .doc and .docx files recently opened in Word. I know a way to build such list: get all links from the 'Recent' folder and filter out matched documents, by .exe name.
But Classic Shell Start menu also shows popup menu for programs like RDC. For RDC client, namely, it shows a list of recent connections. It seems there is a concept of pseudo-documents in Windows, but I have never heard of it. How to get such list for a random .exe file?
Regards,
The shell maintains the list of recent documents. SHAddToRecentDocs allows a program to add an item to the list. The item can be:
A path and filename
A PIDL representing the shell object
(Windows 7+) A SHARDAPPIDINFO or SHARDAPPIDINFOIDLIST structure that identifies a shell item, and associated application.
(Windows 7+) An IShellLink
The key idea from the list and documentation is that the item can be a PIDL, which can represent a fancy kind of 'file'. (What you called a pseudo-document. This is an oversimplification. Read the documentation.)
To obtain the recent files list, use SHGetFolderLocation specifying CSIDL_RECENT and use the returned PIDLIST_ABSOLUTE to iterate the shell items.
If the item is not a file the list can be retrieved through the COM IApplicationDocumentLists which requires an Application User Model ID. This excludes pinned items, for which there is no programmatic access for the same reason that there is no access to the start menu pin list.
There are a lot of caveats to this, which is best explained by the documentation:
SHAddToRecentDocs
Managing the File System
(edited to add information about the jump list, and missing IShellLink from the list.)
Related
I am writing a Shell Namespace Extension.
How may I force explorer to access (and open) items that are not enumerated with IShellFolder::EnumObjects by typing their parsing name in the address bar?
I have seen SFGAO_NONENUMERATED flag which I believe is used to mark such items (so in theory it should be possible, otherwise why do one need this flag?). I don't want to use SFGAO_HIDDEN or SFGAO_SYSTEM because such items could be seen nevertheless.
I am expecting explorer to call IShellFolder::ParseDisplayName with absolute or at least relative path to the item requested. But instead it is calling IShellFolder::ParseDisplayName only for the first segment of the parsing name (basically the first folder's parsing name). After this explorer queries content of each sub folder via IShellFolder::EnumObjects and calls IShellFolder::GetDisplayNameOf to get both display and parsing name of each item enumerated.
Based on this comment from Raymond Chen I understood that it is normal for explorer to rely on both display and parsing names to retrieve the item requested in the address bar. But the biggest issue here is that my items (that I want to obtain) are not enumerated. So explorer does not know about their existence.
Referring my question to this answer: https://stackoverflow.com/a/4016075/698266, in particular step 3 says "Otherwise, if the application has used an Open or Save As dialog box in the past, the path most recently used is selected as the initial directory."
Where does Windows save this information?
Note: by experimenting, it seems to be linked to the application file name without its path - i.e. the same executable copied in different directories "sees" the same last path information, while changing the exe file name makes the dialogs point to the user's Documents directory.
My actual interest is for testing purposes. I need to "reset" this information in order to test my application in conditions similar to a first run.
Windows XP uses HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedMRU and the format of each item seems to be ExeFilename+Path with both strings zero terminated and in UTF-16LE format. The MRU list is stored as a string named MRUList.
Newer versions of Windows uses HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU and HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRULegacy and the format seems to be ExeFilename+ItemIdList (ExeFilename in UTF-16LE and zero terminated). The MRU list seems to be a list of DWORDs in a binary value named MRUListEx and the list is terminated by 0xffffffff.
I would assume that the change happened in Vista because that is when the new IFileDialog was added. LastVisitedPidlMRULegacy is probably used when GetOpen/SaveFileName is called with a custom template and/or hook function.
I finally found the answer myself.
For Windows 10 (this may be different in different versions of Windows, as David pointed up) there's a list of values in the registry that keep track of the executable name and its associated last "visited" path.
The list can be found in this key:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU
In order to reset the default open/save path for a particular program, you have to find the value whose data string (UNICODE) starts with your executable name and delete it. If you watch at the data string, you'll notice that the last used path is there, after the executable name.
Is there any way to find quickly the program behind a rexx/clist panel.
I know that i have check one by one all the panle librairies to find the panel.
But it takes lot of time.
Thanks
First step is is to turn panelid on with the ispf panelid command
panelid on
This will list name of panel on all ISPF panels being displayed
Actually you do not need to search each panel library, you can use Ispf rexx program
to allocate a DataId to ispplib and edit using the DataId i.e.
/* rexx */
address ispexec
'LMINIT DATAID(didVar) DDNAME(ISPPLIB)'
'edit DATAID('didVar') memeber(panelname)'
'lmfree DATAID('didVar')'
Note: If you make changes while editing, the changes are saved in the first library in the list. So if ISPPLIB is setup as
my.panels
test.panels
prod.panels
any changes will always be save in my.panels
Note: if you edit without a specifying the member, the member list will include a dataset number relating to the top level where the panel will be picked up from.
Note: There is almost certainly a limit on the number datasets that can be accessed this way. So if there are a lot of datasets allocated to ISPPLIB, there could be issues.
Hopefully there will be a
Relationship between where the panel is stored and where the rexx/clist is stored
relationship between the panel name and the rexx/clist name; often they are nearly the same. Some times the panel might have a P at a certain character position while the rexx might have a R
If there is no relationship between the panel and the Rexx/clist; you will have to search for it. You could set up a batch search for to search for the panel in all the rexx/clist libraries. A bit of a pain to set up, but it only has to be done once and then you have it for future use.
If you want to get really smart you could use the LM services to extract rexx/clist libraries
Building on some of what #Bruce Martin said, type TSO ISRDDN on any COMMAND ==> line in ISPF. Use the member command to search your SYSPROC and SYSEXEC concatenations. You can also use SRCHFOR when in a member list, looking for the panel name.
I suspect this may apply to multiple programming languages, but in this context I am referring to .NET.
When I use System.Diagnostics.Process.Start, I can include, as an argument, a System.Diagnostics.ProcessStartInfo object. One of the properties of ProcessStartInfo class is Verb (type of string). There is also a string[] property of Verbs which seems to contain the list of permitted values for Verb.
I notice that within the Verbs array there is a value for "Print" and a value for "PrintTo". What's the difference between the two? I tested both and they both seem to cause the file to print to my default printer.
According to this MSDN article, PrintTo is basically present to support drag-and-drop operations for printing (dragging a document over a printer icon, for example). It sounds like it's probably not meant to be used by your code.
The printto verb is normally used when the user drags a file and drops it on a printer shortcut. You need to supply at least two arguments, the first one is the file you want to get printed, the second one is the printer name. Registry entries on my machine use additional arguments but it is quite unclear to me what they may be.
Background
Lately I've become a fanatic that everything I type while working on a computer should be compatible with "DRY". If there's anything I have to type more than once in any context, I want some kind of user-aware auto-complete option to do some of the work for me -- always -- no exceptions.
Having to work under Windows, I've looked at GUI solutions to make this insane goal a reality.
The (almost) optimal solution
If you have a moment, open up Firefox 3.0 and type a few keystrokes into the address bar. You will notice that it performs a kind of Incremental Autocomplete based on space-separated sub-strings of whatever you type. Another place in Firefox that does something similar is the about:config URL.
This is sub-optimal, because I don't want this in Firefox only. I want to use this everywhere.
The Question
Does anyone out there know of a widget or app that does nothing but insanely good incremental auto-complete that can be used as a general purpose "run everywhere" tool? Something that allows the user to: 1) maintain one or more "completion candidate files"; 2) pick one of those files as the source for Firefox 3.0 style completion; 3) return the result (or blank if the user canceled), and do those three things only?
Details
Here's how it should work:
STEP1: user saves or more csv file(s) (or other easy-edit format) somewhere in his hard-drive
STEP2: user creates a Windows Script Host script or a batch file (or whatever) instantiates the FilterAsYouType GUI
STEP3: user runs the script file, and the script file instantiates the GUI, telling it which CSV file to use as the source of all potential completions
STEP4: the user either chooses one of the completions, supplies his own text that is not in the list, or cancels out without supplying anything
STEP5: when the user is done the script saves the result to a variable and does something with it
Here is some pseudo-code for the script:
include "GenericTypeaheadWidget";
var gengui = new GenericTypaheadWidget('c:\docs\favorite_foods.csv');
var fave_food = gengui.get_user_input();
if(fave_food != ''){
alert('you chose '+fave_food+'!');
}
The rationale
The goal is to just have a way to always be able to do auto-completions from a list of arbitrary items, even if the list is a couple thousand items, and not have to rely on it being built into some IDE or standalone application that only accepts certain kinds of input or has an overly-complicated API relative to the simplicity of this task.
CSV (or text or sqlite database) would provide a way for me to self-generate "candidate lists" or "history logs" and then just use those logs as the source of the possible completions.
The disclaimer
I've tried several GUI "launcher" programs, command-line engines like power-shell and scripting shells, the regular plain old command-line history with varying degrees of satisfaction. The problem with these is they all do extra superfluous stuff like searching directories or built-in commands. I just want nothing but whatever is in the CSV file I happen to be pointing at.
I'm wondering if there is any simple tool that does nothing but what I'm describing above.
UPDATE: It looks like this question is very closely related to Graphical Command Shell, which captures the essential idea presented here.
You should really try Launchy - it's exactly what you're looking for, a "run anything" with intelligent autocompletion. It completely changes the way you interact with a Windows PC.
And it has open source-code, so you can borrow its autocompletion code if you want to roll your own interface.