I am desperately attempting to guess how the localized filename for photos can be retrieved given the path to that file. For instance, given the path
c:\images\jellyfish.png - Win 7 explorer and the built in image viewer program both display the word "Méduses" for a french win 7. Does this hold true for other versions of windows ?
GetFileTitle only removes the extension and folder path giving me 'jellyfish' which is not what I am after, and after having read through MSDN and google it seems that the Windows Media Format's http://msdn.microsoft.com/en-us/library/dd798508(v=VS.85).aspx interface wouldn't help here. Either I have lost my googling skills or this is very poorly documented. Help please ?
thank you
I'm not sure about this case specifically (I've never encountered localized filenames in that form) but the only officially supported way I know of to get the localized filenames for system directories and the standard Windows applets, etc., is to use IShellFolder::GetDisplayNameOf.
So briefly, you need to get a PIDL for the file (SHParseDisplayName), bind to its parent folder (SHBindToParent), and then query for the display name using the SHGDN_INFOLDER flag.
Addendum: An even easier way (which I completely forgot about) is to use SHGetFileInfo to get the display name with the SHGFI_DISPLAYNAME flag. This means you don't need to muck around with PIDLs. SHGetFileInfo is essentially a wrapper around the various shell COM classes like IShellFolder - either way, the key is to use the shell to get the display name rather than the underlying API functions.
Related
So I've recently been looking into the Control Panel, to try to see how I might be able to create a custom applet for it, like sometimes you get a custom one when you use a printer, and I just can't seem to figure out how to make one. I've tried opening one of them in a code editing software, and assume that they are compiled as all I get is a bunch of random characters, but I'm not quite sure whether it is or not. I've looked for anything related to it, but the closest thing to an answer I have is something about trying to make the applet show up, but it doesn't say how it's made, so its not really useful.
Thanks in advance.
There are two types of control panel applets:
.Exe files. These are normal applications and can be written in any language.
.Cpl files. These are actually normal .DLL files and can be written in anything that can produce a PE DLL with a named exported function (C/C++, Delphi or if you must, C#).
Support for .Exe applets started in Vista and is now the preferred method according to Microsoft.
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.
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.
Where can I find the orginal vb6 ( or windows ) icon? (.ico files)
I need, error, warning, question, and information icons which come up on the messagebox.
Thanks a lot.
As the icons can differ for each OS version, you can get the icons from Windows using LoadIcon() passing one of the standard icon IDs.
See http://msdn.microsoft.com/en-us/library/ms648072.aspx for details.
If you want them as .ico files, you can extract them (on your development machine) from user32.dll using a resource editor.
(Updated with corrected info from Cody Gray)
The standard Windows message box icons have changed many times across the various versions of Windows. They're included with a couple of the system DLL files, but you shouldn't try and extract them dynamically yourself. As I mentioned in a comment to another answer, the ID numbers are undocumented for a reason: namely because it's possible for them to change in future versions of Windows or even in future Windows updates. There's absolutely no reason to go through the effort trying to extract them, either. Windows will already retrieve them for you, if you ask nicely.
The nice way of asking is to use the LoadIcon function, and specify the IDI identifier of the icon you want. Windows will return an HICON value, or a handle to an icon resource.
Since you mention that you're using VB.NET, you can also use the SystemIcons class, which has static properties to return any of the common icons. This is a .NET wrapper that saves you from having to P/Invoke the LoadIcon function from the Windows API yourself.
Better yet, if you just want to display a message box containing one of the icons, all you have to do is call the MessageBox API function. Tell Windows the MB_ICON value that you want, and you're off. As before, this has already been wrapped for you by the .NET Framework in the identically-named MessageBox class.
The benefit of both of these functions is that they'll always return the correct icons regardless of the current version of Windows. A comment made attempting to clarify the question seems to suggest that you want to use the old icons on a current version of Windows. But of course, you do not want to do this. The icons have been updated throughout the Windows shell for a good reason, and your application should take advantage of them. The new icons are more clear and fit in better with the overall system theme. Additionally, if your app still uses the old icons, it will be confusing to users and look very out of place. It's always best to follow standard platform conventions, rather than trying to do "something else", even if you think your "something else" is "better" for whatever reason than the platform default. Your users will not agree, and your application will reflect your shoddy craftsmanship.
Since people who ask this type of question inevitably disagree with me and insist that they must do it anyway, and that it is a "requirement" (whatever that means), I'll point out that the old icons are not available in the newer versions of Windows. The icons have been completely replaced throughout the system for a reason. It's also strictly forbidden by the licensing agreements to extract icons from system DLL files and redistribute them with your application. Don't do this.
Also, before deciding on which icon you should display in your message box, be sure to consult Microsoft's Windows User Experience Interaction Guidelines, which provide some very handy rules on selecting the proper icon to convey the right message and fit with the Windows tone. I provide more information on that in my answer here; very much recommended reading for any Windows application developer.
Edit: It's like pulling teeth to get any more details on this question. I'm not sure why you're so secretive about what you're trying to accomplish, but note that in the future, you'll have a lot better luck including these things in your question to start with, rather than hoping people will pull it out of you. Most people aren't nearly as persistent as I am.
Anyway, you finally mention that you're doing some type of interop between VB 6 code and .NET code. That should not be relevant in the case of the message box icons used. The VB 6 MsgBox function is 100% equivalent to the Win32 API MessageBox function and the .NET MessageBox class that I discussed earlier. All of them are going to use the current system icons, and it shouldn't require any extra work to make them look the same. Ensure that you've passed the same icon specifier to all of the functions. Here's a table for convenience:
VB 6 "MsgBox" Icon Constant | VB.NET "MessageBox" Icon Identifier
---------------------------------------------------------------------------------
vbCritical | MessageBoxIcon.Error
vbQuestion | MessageBoxIcon.Question (DEPRECATED -- do not use)
vbExclamation | MessageBoxIcon.Warning
vbInformation | MessageBoxIcon.Information
Note that the "Question" style icon has since been deprecated and you should not use this value. If you're still using it in the VB 6 code, you should change that code to use a different icon (or no icon at all). The above-linked Windows User Experience Interaction Guidelines provide more details on why this icon has been deprecated and how to choose a suitable replacement.
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.