The Favorites Menu

[LarsJ]

Bluesmaster, No it will not work for a virtual folder. But it is possible to extract the structure and items of the Control Panel. See here. Then you can create a menu.

[Bluesmaster]

@BrewManNH:

_WinAPI_ShellGetKnownFolderIDList seems to always return 0 for virtual folders. ( btw I could find any usage through google, it also seems to be a very rare used fcn )

but it pointed me to

_WinAPI_ShellGetSpecialFolderLocation 

which will work...well at least somehow:

$controlPanelGUID = "{5399E694-6CE5-4D6C-8FCE-1D8870FDCBA0}"
$targetFolderPIDL =  _WinAPI_ShellGetSpecialFolderLocation( $controlPanelGUID )
$oMainFolderMenu.SetShellFolder( $NULL , $targetFolderPIDL , $NULL , BitOR( $SMSET_BOTTOM, $SMSET_USEBKICONEXTRACTION ) )

so it seems to be possible in principle ( ok its mixing up some folder/ file elements )

But is it possible to start directly in the control panels category or all elements -view?

Edited January 24, 2014 by Bluesmaster

[LarsJ]

Bluesmaster, You seem to be right. It is working for a virtual folder.

I do not think that the problem of files and folders are mixed up has anything to do with the script. It seems more to be a problem of the Control Panel. This issue is also the case in the example in the link in post #21. In this example I have added code to handle the mixed up items.

I've just seen that there was a question too. I'll try to figure that out.

Edited January 24, 2014 by LarsJ

[Bluesmaster]

I have seen the example in #21 it is great work. But it is also a bit scaring...it seems whenever I ask a question you have done a whole project for that already ^^.

It would be very nice if you can figure out the problem with the wrong root node. I would like to include the control panel as entry in the context-menu-browser

regards

[LarsJ]

This is some of the Control Panel subfolders on Windows 7:

 

[\All Control Panel Items] = ::{26EE0668-A00A-44D7-9371-BEB064C98683}\0
[\Appearance and Personalization] = ::{26EE0668-A00A-44D7-9371-BEB064C98683}\1
[\Hardware and Sound] = ::{26EE0668-A00A-44D7-9371-BEB064C98683}\2
[\Network and Internet] = ::{26EE0668-A00A-44D7-9371-BEB064C98683}\3
[\System and Security] = ::{26EE0668-A00A-44D7-9371-BEB064C98683}\5
[\Clock, Language, and Region] = ::{26EE0668-A00A-44D7-9371-BEB064C98683}\6
[\Ease of Access] = ::{26EE0668-A00A-44D7-9371-BEB064C98683}\7
[\Programs] = ::{26EE0668-A00A-44D7-9371-BEB064C98683}\8
[\User Accounts and Family Safety] = ::{26EE0668-A00A-44D7-9371-BEB064C98683}\9

Run cpPrint.au3 here to create the list.

You can get the PIDL with SHILCreateFromPath. Note that FileExists will fail.

However, there is a problem. A lot of these items are containers or pages that appear to be folders. This means that they are displayed as folders in the menu with an arrow to the right. Nothing happens when you click on such an item. They should have been shown as executable programs in the menu. It seems to be difficult to find a solution to that problem.

[Bluesmaster]

Hello LarsJ,

I am not sure if I understand you right. "SHILCreateFromPath" cannot create PIDLS from GUIDs how should it generate PIDLS for subelements of GUIDS?

#include <WinAPIShellEx.au3>

ConsoleWrite( DllCall( "shell32.dll" , "uint", "SHILCreateFromPath", "wstr",   "{26EE0668-A00A-44D7-9371-BEB064C98683}\1"  , "ptr*", 0, "dword*", 0 )[ 2 ]     & @LF  )

ConsoleWrite( _WinAPI_ShellGetSpecialFolderLocation( "{26EE0668-A00A-44D7-9371-BEB064C98683}\1" )   & @LF  )

ShellExecute( "explorer" , "shell:::" &   "{26EE0668-A00A-44D7-9371-BEB064C98683}\5"   )

executing this demonstrates it. "_WinAPI_ShellGetSpecialFolderLocation" can do, but it has no effect on the "wrong-root-problem"

I can upload the whole source ( important is only line 255-258, the rest is mainly your code condensed )

contextBrowser.au3

 

PS: the folder-file problem is not a big problem to me

Edited January 25, 2014 by Bluesmaster

[LarsJ]

SHILCreateFromPath( $FavsProgsFolder, $pidl, $rgflnOut )
SHILCreateFromPath( "::{26EE0668-A00A-44D7-9371-BEB064C98683}\0", $pidl, $rgflnOut )

You find SHILCreateFromPath in ShellFavsProgsMenus.au3.

Edited January 25, 2014 by LarsJ

[Bluesmaster]

ConsoleWrite(  DllCall( "shell32.dll" , "uint" ,   "SHILCreateFromPath"   , "wstr" ,   "{26EE0668-A00A-44D7-9371-BEB064C98683}\1"  , "ptr*", 0, "dword*", 0 )[ 0 ] )

it returns a number ( not sure its PIDL ) but it crashes when SetShellFolder(...)

 

i think they solved it here: http://stackoverflow.com/questions/14325953/why-would-the-pidl-for-the-control-panel-be-different

but due to my bad english and my lack of understanding the backgrounds of the whole shell-api I do not really understand how to apply it to autoIT. I tried to use the new SHParseDisplayName

$targetFolderPIDL = DllCall( "shell32.dll" , "long" , "SHParseDisplayName", "wstr" ,  "{26EE0668-A00A-44D7-9371-BEB064C98683}\0", "ptr", 0, "ptr*", 0, "ulong", 0, "ulong*", 0)[ 0 ]

but it returns the same as the deprecated SHILCreateFromPath so I have to give up now. I am sure you could solve this using the  contextBrowser.au3 in post #26. 

So if you have some minutes anytime this would be great

best regards

Blues

[LarsJ]

Wrong:

"{26EE0668-A00A-44D7-9371-BEB064C98683}\1"

Right:

"::{26EE0668-A00A-44D7-9371-BEB064C98683}\1"

You need the two colons in the front.

[Bluesmaster]

What could we have saved time if I had tried that first. What a shame 

Thank you

[LarsJ]

This example was created under 3.3.8 and based on APIConstants.au3 and WinAPIEx.au3 by Yashied.

The original example runs under 3.3.10 without any changes at all. But a lot of unused constants and functions are included.

In 3.3.10 the two UDFs are divided into several smaller UDFs. This makes it much easier to just include, what is needed. This update only includes the necessary UDFs. You find a new zip in bottom of first post.