In Windows 7, there's a Favorites tree that appears in Explorer that the user can dynamically add items to.
How can I retrieve these shortcuts from code?
In c#, I know I can do the following:
Environment.GetFolderPath(Environment.SpecialFolder.Favorites)
but that seems to be an entirely different Favorites folder.
I've googled around but haven't found anything yet.
You want FOLDERID_Links. I don't think there is a .net constant for this but you can PInvoke SHGetKnownFolderPath, use COM (CLSID_KnownFolderManager/IKnownFolderManager) or the .net WinAPI Codepack.
Related
I have an application and would like to know what GUI toolkit was used to implement it. The list of DLLs which it uses at runtime wasn't very enlightening, I didn't recognize anything. Tools like Spy++ or UISpy show that the windows have class names like wcl_manager1 (apparently toplevel windows) or wcl_internal_window_class (for anything else). Most of the controls (line edits, check boxes, buttons) don't even have a native window, i.e. no HWND associated.
Does anybody know what GUI toolkit this might be?
Look up ProcessId property and you'll figure it out.
In my case it was CiscoJabber.exe with "20200" window name.
I want to use the function "findwindowex" (windows API)
I wanted to know what appropriate values for the parameter "ClassName".
Are the tables that are here show the possible values?
If not - where can I find details of all types "ClassName"?
(Am I understood? I do not know good English.)
No, those are the names of some classes registered by the system. A great many Windows applications will be built with classes registered by those applications.
If you wish to find the name of the window class used by a particular window, use GetClassName().
You need to use a tool like SPY.EXE that's included somewhere as part of the win32 SDK. It shows the classname of the window currently under your cursor.
Microsoft Spy++ I believe when you hover over the window after clicking the Find button it shows all the information about the window.
I don't know what their official name is, but I mean these things:
Is there an official API for creating those in my own program?
And related question: Did you ever see these "split menu items" used anywhere other than the start menu? Where? This could point at an API.
Glancing at my own start menu, I'm guessing that most are generated the same way "Recent Documents" used to be done. i.e., observing the files that programs open.
As for new APIs, this page might be a good place to start sniffing around: http://msdn.microsoft.com/en-us/library/ee461765%28VS.85%29.aspx
To create tasks like internet explorer etc, use ICustomDestinationList->AddUserTasks(), the recent items should show up for file types you are registered to handle (They are added by the open/save dialog or manually by calling SHAddToRecentDocs())
In Vista, I have been using an IFileSaveDialog to let users pick a "save-as" folder. Users export a folder of images, say, and need to choose a new or existing target folder.
Briefly, the code goes like this:
IFileSaveDialog* dialog; // created
dialog->SetOptions(FOS_PICKFOLDERS);
dialog->Show(NULL);
dialog->GetResult(&shellItem)
In Windows 7, the FOS_PICKFOLDERS option appears to have been disallowed (and is marked as such in the API). The return value on the SetOptions call is E_INVALIDARG. If I use a IFileOpenDialog, I'm allowed to set the folders option, but the user is prompted with an error when choosing a nonexistent folder (despite my setting flags suggesting not to do this).
Is there an alternate way to get the new IFileDialog to act as a "save folder" dialog?
[To head off some comments, the SHBrowseForFolder API still exists, but is still not an acceptable solution for our UI deciders.]
The reason for this can be found in the documentation:
FOS_PICKFOLDERS: Present the Open dialog offering a choice of folders rather than files.
Using FOS_PICKFOLDERS for "save" was never supposed to be supported - but Vista didn't enforce it. Use IFileOpenDialog instead and you're good to go.
You are picking an existing folder (not specifying a folder to create), so open was always the correct choice.
I haven't played around with the Windows 7 dialogs yet, but downloaded the Windows® API Code Pack just this morning as I am implementing the Thumbnail Toolbar and Icon Overlay in the application I am working on. It'll probably point you in the right direction.
I understand the process needed to customize a right click menu going through the regedit etc. However I need to the ability to go multiple levels such as in applications like WinZip. Here's a picture for clarification of what I need
alt text http://img14.imageshack.us/img14/9658/multiplemenus.jpg
You need to write a Shell Extension; there is a guide for writing one in managed code (C#) here. It will involve doing a bunch of interop and implementing COM interfaces that the windows shell will consume, namely IShellExtInit and IContextMenu.
However, one could argue that writing a Shell Extension in managed code is not advisable; it will force windows explorer to load the CLR, (or any app that uses the standard windows 'Open File' dialog) - native code (C++) would be a better choice for this.