I have an application which when I install in Windows 10, need to show up in left navigation pane. Now, I checked how other applications like OneDrive, DropBox which when installed in Windows 10, show up in the navigation pane. Apparently, it was mentioned that there is a DWORD value in registry which controls this behavior which is System.IsPinnedToNameSpaceTree. This value should be set to 1. But, when I tried to create this value in registry manually for my application's registry entries, it did not work for me. I am kind of stuck here. So, can somebody please help me in this regard ?
After lot of search and studying Dropbox entries in the Windows registry, I figured out the answer. We have to create new keys and sub keys with the following values similar to this GUID {E31EA727-12ED-4702-820C-4B6445F28E1A}:
Create a new GUID for the application online.
Search for the Dropbox GUID as mentioned above and add keys/subkeys similar to Dropbox.
After putting entries similar to Dropbox into Windows registry, I am able to see my application in the left navigation pane :-)
However, there is still one issue with this change. After changing the registry entries, a folder in Desktop got created with the name of my application and there is not even a delete option on it, somewhat like Recycle Bin. Any idea how to fix this issue ?
Related
We just virtualized a Windows server in Azure and everything in working fine on Client side, but we are not being able to solve the indexing search problem.
When you have a local drive, Windows can index the path and searches works fine using Windows menu/search box in task bar. But for shared drives it seems to fail.
In Windows Explorer the search pretends to work, but it takes forever to find a file or folder. And sometimes it just won't move anywhere. So it is not an option for users since them are used to search using menu bar.
We have tried to change drive properties in Right button to Shared Driver > "Allow files on this drive to have contents indexed in addition to file properties, but it was already enabled.
When we try to disable it, it prompts an error saying that the user doesn't have permission to do it, but it does anyway. And when we try to re-enable, the message prompts again, but it is enabled with no problem at all. But once again, nothing changes and Initial Menu Search just won't work.
Does anyone knows if there is a solution for that?
For me it seems to be an server setup since I see that permission error, but, as far as I know, if the shared driver is already mounted, I can't see a reason why Windows can't index it.
Ps.1: In the shared drive security tab, the System has full permissions.
Ps.2: If there is a solution for this, is that possible to solve it on the Windows server Side so we won't need to access client by client to change it manually?
enter image description here
Please check the following setting and see.
1.First thing is to check network location is being indexed. open File Explorer right-click on the mapped network drive that you need to index, then select the Properties and Make sure that, the Allow Files on this Drive to Have Contents Indexed checkbox is selected.
You have already done this step
2.try to check the search options for network drive in file explorer, go to view tab>>click on Options Icon and choose the change folder and search option menu it will open the folder options dialog box and select search tab and make sure first option is not selected
3.check server side Indexing
4.we need to make sure search service needs to be running.
Open services.msc check for the wndows search service and try to restart the service.
5.Go to Settings on the Windows 10 desktop, then click on Search, followed by Searching Windows scroll down and try to run the indexer troubleshooter
Reference https://learn.microsoft.com/en-us/troubleshoot/windows-client/shell-experience/fix-problems-in-windows-search
I now experimented with windows registry, but I deleted a "Create new folder..." from the context menu. Now, I have a little problem; in which registry hive is this point stored? I want to restore "Create new folder..."
The question is mostly not for developer. Nevertheless the part of registry which are responsible to create a folder you will find here:
HKEY_CLASSES_ROOT\Folder\ShellNew
It is of course not the only part which you could delete/rename to make the corresponding item in the context menu disappear. I general HKEY_CLASSES_ROOT part is the place which mostly responsible for the problem which you try to solve. It you want to examine your problem more exactly the Process Monitor could be helpful for you. You should have a little experience in setting of filters to reduce the output which you need to analyse.
I Assume that you did not backup the registry before that :)
I suggest to find some good dedicated tool
Here there is some information about managing the Context Menu Entries:
http://windowsxp.mvps.org/context_folders.htm
Doing it manually will be extremely hard ?
I have been trying to add context based right click in windows explorer for a file of extension L5X. I have tried HKEY_CLASSES_ROOT\l5xfile\Shell\convert\command and set the (Default) key value to the program I want to have open the file. (I want it to say "Convert" on the context menu) My first issue seems to be that in .NET (even when running elevated) I cannot change the Default key's value. My other issue is changing that Default key value doesn't do anything to the context menu. I would really prefer a no reboot required solution.
Also, I really need this to work on WinXP all the way up to Win7 (including Server 2003, 2008 and 2008R2). If I need to detect OS and do things differently for different OSes, I will but I'm really stuck here.
PS, I tried the solution found here with no luck.
You need administrator rights to write to HKEY_CLASSES_ROOT, HKEY_CLASSES_ROOT is a merged view of HKEY_LOCAL_MACHINE\SOFTWARE\Classes and HKEY_CURRENT_USER\Software\Classes. If you want to install it for just the current user, write to HKEY_CURRENT_USER\Software\Classes
\l5xfile\Shell\convert\command might not be the correct path, when windows looks for context menu entries for a filetype, it first looks in HKEY_CLASSES_ROOT\.EXT, then uses the default value it finds there: HKEY_CLASSES_ROOT\%defaultvaluefrom.EXT%\Shell\*
XP added a new key HKEY_CLASSES_ROOT\SystemFileAssociations designed for non-primary actions where you don't care about the ProgId/Class (The l5xfile part)
MSDN documents all these registry paths and settings, see: File Types and Verbs and File Associations
Does anyone know (Because on microsoft forums nobody answered me), how can I find what app has which automaticDestinations-ms file in %appdata%\microsoft\windows\recent\automaticdestinations ?
That's the folder where Windows 7 stores its jump lists, and I want to know how to automatically/programmatic find the relation between each file and an application.
At least, even manual I didn't found any pattern, just to look after file extensions in the files, because some programs open files with the same extension (like images), so this method it's not OK for all programs.
Do you have any other idea? Maybe knowing the format of those files?
Thanks.
the GUIDs appear to persist.
I was trying to edit my control panel jumplist - I found where the "Realtek HD audio manager" control-panel-applet-title-string is (using resource hacker on "C:\Windows\System32\RTSnMg64.cpl"), and restored it's original title ("Dell Audio" - 'cause I'm OCD:) but the original pinned Realtek entry is stuck.
A quick filesearch for pinned took me to
C:\Users\Jonny\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned
but I really needed to be # C:\Users\Jonny\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations
If you use something like Nirsoft's Jumplist View you can see the entries etc. Sort by "application ID" column to see jumplists by application. You can even change the monitored folder (advanced options).
I'm going to have to delete and recreate my control panel jumplist (7e4dca80246863e3.automaticDestinations-ms).
TIP: If you're not sure which is which, try pinning a new jumplist-entry to an application. This will appear at the top (if sorted by "record time")
The best way to find out is to sort the files by date modified, then interact with your machine, eg open a file with Powerpoint, look and see what file moved to the top. That is probably the file for Powerpoint, which you can confirm by opening it and looking in it.
Then you could build a table of magic guids, and search for those in the registry to see if there is an obvious key connecting the guid to an application id.
Here is a list of 620 applications here with the corresponding App ID byEricZimmerman
https://github.com/EricZimmerman/JumpList/blob/master/JumpList/Resources/AppIDs.txt
eg 0a1d19afe5a80f80|FileZilla 2.2.32
last update 12 days ago
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.