Goal
Let me start with my final vision of what I'd like to be able to do first: In Windows, I'd like to be able to use a global keyboard shortcut that I define (say, Ctrl+Alt+C) to copy the full path and filename of the open document in the foreground application to the clipboard.
This would be useful to, for example, be able to subsequently paste the path & filename into an "Open File" dialog in an email client to attach that document to an email, without having to manually browse to the target document in the filesystem.
Specific Question
Now, the specific part of how to do this that I'm interested in how to implement is: How can I get the path and filename of the current "open document" of any arbitrary currently-running Windows application. (If this can't be done with any Windows application, then the next best thing would be for this to work with as many applications as possible.)
Obviously, this wouldn't apply to some applications that don't necessarily have the concept of a "currently open document" that corresponds to a file on the local filesystem, such as an email client, an IM client, or (usually) a web browser.
Application-Specific Solutions
I'm aware that it's possible to write application-specific solutions to do this. For example, the following MS Word VBA subroutine will copy the filename and path of the open document in Word to the clipboard:
Dim myDataObject As DataObject
Set myDataObject = New DataObject
myDataObject.SetText ActiveDocument.FullName
myDataObject.PutInClipboard
However, what I really want is something that will work for any of the applications on my system (or, again, for as many of them as reasonably possible) without having to try and write an application-specific solution for each one.
Idea: Recent Documents Folder
One idea: Could the Recent Documents folder (and/or its underlying Windows APIs) somehow be leveraged to help with this? It seems to have information about the same concept of "open documents" that I'm interested in here, that apparently applies across various application types. (Looking at the contents of the Recent Documents folder on my machine, I see entries in there that were apparently made for documents that I opened with various applications including MS Word, MS Excel, Eclipse, Adobe Acrobat Reader, Paint.NET, TOAD, and Notepad2.)
Preferred Solution Language
I'd prefer solutions in C# or C++ code, but I'm open to any suggestions for how to go about doing this, regardless of implementation language!
Windows 7?
Update 11/2009: Now that Windows 7 is widely available, I figured it might be worth coming back to this question and asking: Does Windows 7 provide any new APIs, or any other mechanism, that would help with what I'm trying to accomplish here?
The best you could probably do is look at the recent documentation registry keys, and get the list of most recent documents. Some sample code for working with this data is in this CodeProject article. This is saved in:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
However, this isn't going to show you whether a document is currently open or not. You could potentially check the title of all open applications, since many applications put document names in their window titles, but this is not a requirement, and many applications do not do that.
There is no mandatory mechanism for an application to specify its open document, so this is not generically possible.
Related
I want to do a very simple task, and yet somehow the hundreds of questions on SO surrounding the topic always manage to skirt answering this exact one (from what I can find).
The task is this: I want to view the source file that holds the Clipboard contents.
I know that older Windows OS had an option for Clipboard Viewers, and for newer OS you can use third-party viewers, but I want to view the actual source file itself. It has to be stored in some file somewhere, doesn't it? This answer gets close by at least letting me view the text natively without 3rd party software, but I still can't figure out where it's pulling its information from. I don't want the user-friendly version, I want to see whatever the computer is using (HTML, XML, UNICODE, C, or even binary, I have no idea).
There has to be some way to view the contents of that file in Command Prompt (or PowerShell), doesn't there? Why is this information so hard to find?
The short answer is through invoking the static method from the System.Windows.Form.Clipboard class in the .NET framework.
[System.Windows.Forms.Clipboard]::GetText()
This will work in powershell as-is, and will return to you whatever is currently stored in your clipboard.
Now, without going beyond the scope of our main topic being powershell/CLI, you can peruse through the class in User32.lib or User32.dll.
See: https://msdn.microsoft.com/en-us/library/windows/desktop/ms649014(v=vs.85).aspx
My original short answer should be sufficient for what I think you're looking to do, which is return the content of whatever is in clipboard back out to your powershell/cli host in plaintext.
This information was easily found by googling
powershell get clipboard contents
Also, if you want a more in-depth walkthrough:
http://powershell-tips.blogspot.com/2011/05/handling-clipboard-with-powershell.html
Windows is not a GNU/Linux OS. AFAIK there isn't really a clipboard daemon that stores content in a plaintext file somewhere on the filesystem. With .NET being natively available in powershell, you can just invoke these classes directly to get what you need.
How can I access Windows Search index data from Emacs? Knowing this would be useful for example when writing a minor mode that integrates Windows Search into anything mode or ido-mode.
By Windows Search, I mean the Windows 7 feature that lets you find documents by pressing Start and typing part of document file names (or part of document contents).
Here is a little Python script providing a command line utility for Windows Search. You need to install Python for Windows extensions to use it.
Accessing Windows Search from within emacs is going to be a bit difficult because the API Microsoft provides is strongly skewed towards the Microsoft programming environment. Judging by the MSDN docs, the easiest path would be putting together a SQL query that Windows Search will accept and sending that to a PowerShell/VB script that knows how to send that query to Windows Search. You'd then tell anything/ido/icicles to incrementally send input to such a script, parse the results, and display those.
The task that you are attempting is very difficult, and much of the difficulty comes from the fact that you are trying to get two programs from very different worlds of programming to talk to one another. Completely apart from the FSF/GNU folks actively disliking Microsoft, the design of the Windows API means that the least-effort way of dealing with Windows is to use the Microsoft toolchain. This in contrast to the Unix "API" of sending plain text through intermediary programs, pipes, and sockets.
I want to allow the displayed name of my application's shortcut in the start menu to appear in the user's local language, if we have a string available for it.
I have found a question that deals with how the localized strings are referenced in storage, but while I could just muck around editing the desktop.ini file directly, I would highly prefer a fully programmatic interface for solving this issue, i.e. an API similar to the IShellLink and related interfaces already used to set up shortcuts. IShellFolder::SetNameOf initially sounded like it would be able to deal with this, but on my second read of that page, it seems it will always rename the physical file.
My application already uses indirect strings for having file associations localised in the shell, this wasn't a major issue setting up since it is well enough documented, but I can't seem to find much documentation on display names of shell links.
I am using InnoSetup for my installer.
That's almost embarrassing, right after posting the question I did another search on MSDN, and found this:
SHSetLocalizedName Sets the localized name of a file in a Shell folder.
I am trying to integrate the Windows desktop file search feature into MSAccess to search files based on content .
For eg:
I want to search for all the files containing "Noble" in its content( preferably it also searches PDF content ) in a specific fodler(s) form MS Access.
Can anyone suggest good place to start?
I've been down this road. Windows Search or Google Search are quite problematic, particularly if you want to search data on a server, because you have to maintain indexes on each client workstation. There's a server version for Windows Search but the API is very complicated.
Office versions from 97 to 2003 provided a FileSearch object that was quite versatile, but that was removed in Office 2007.
Because of that, I coded up a FileSearch class module for use in Access to replace the core functionality provided by the old FileSearch object. You can find the code on my website. It still needs a lot of work, but I've had in production use since June 2009. It does have some issues on Vista/Win7 if you try to search folders that aren't available to non-admin users, and some other problems, too. I've wanted to get back to it and change the progress bar to use WithEvents, but as I've already got a working implementation for the two applications where I'm using it, it wasn't really worth my time.
Try it and see if you have any problems. For searching files for strings in those files, it works pretty well (much faster than the built-in WinXP search functionality!), but it's not going to be as fast as Vista/Win7's search, since it's not index-based.
At work I use Google Desktop because we're still on Windows XP and I don't know if that is the reason, but I'm not impressed with Windows Search.
I don't even think you can go into Access itself and do a search to look everywhere (data, objects, code, etc.).
For some time I've noticed how much the File Open and File save dialogs vary between Windows itself and Applications. In Delphi for example (which I use) you can use the built-in dialogs (which have a folder tree) and direct calls to the Windows API which produce variants of the Windows version, with or without large buttons for 'Desktop', 'My Computer' etc (At least on XP).
As an application developer I'm interested in providing the User with a clean, simple way of loading and saving files. Typically, this requires that I propose a preferred folder where my Application data files are stored but that I allow the User to access other folders - often the desktop and other local drives, and sometimes the network - without difficulty if required.
With the introduction of Vista, we seem to be favouring a 'bits missing' folder navigation tree for Windows dialogs and now, Windows 7 has another 'line-less tree' for navigation. I suspect that if one conforms to Microsofts assumptions and stores everything in ~/documents it's not a big problem. However, if one has to start at the root of a drives tree and there are many directories then it's a right pain - there is no horizontal scrolling so directory names get truncated.
My question is - what do other Application developers use? I wonder whether I should be following this Windows lead or simply sticking to a simple cut-down version of File dialogs over which I full control but risk falling into the past....?
Thanks
Brian
Always use the OS defaults - it'll be what your users are used to, and what they expect. Whatever you do, don't astonish the user. Whatever you do, please don't write your own file-open/file-save dialog.
FWIW, I'm not a great fan of Vista's file-open dialog (why do I have to work so hard to navigate my folders?), but I'd rather that than have to get to grips with something new. The less things your users have to learn, the easier your product is to use.
Since I am currently only coding for customers with Windows XP (in a corporate environment that isn't upgrading just yet) I use the standard dialog boxes.
When we do upgrade, I will most likely continue to use the standard old fashioned dialog boxes, until our customers are ready for a change.
In all honesty, I involve at least a few users in the development process, and I won't start new features unless I can bring one in to sit in front of my development PC to see how it works, and they sign off on it.
For those apps that we write for our web site, we tend to be conservative as well... Focus on clean, understandable design, and introduce fancy new features only when there is a compelling reason, and even then, we tend to involve focus groups.
So all that was a long way of saying "Ask your customers". Give them what they want.