Can i set startup folder of tfileopendialog to a shell (non file system) folder, and how? If not, is there other way to save the full dialog state for the next call of the application?
Ok if no one will bother answering i will.
dialog.shellitem.getdisplayname(SIGDN_DESKTOPABSOLUTEPARSING,pch);
assigns "::{guid}\..." value to pch variable, and this string can be used to set dialog.defaultfolder or dialog.filename. it can also be used in conjunction with
shellfolder.getdisplaynameof(pidl,SHGDN_FORPARSING,strret);
to identify a folder.
Related
I want to create generic shortcuts in Windows 10 using a target path
extension of the shell path, something like
%windir%\explorer.exe shell:AppData ..\Local\Temp
%windir%\explorer.exe shell:AppData works by itself, takes me to roaming userfiles.
I could use
%windir%\explorer.exe shell:UsersFilesFolder
which would take me to %UserProfile% and append from there (if I could find out how) only it would be handy to be able to go up a level if possible as well.
I can't work out
How to append a further couple directories into the shortcut target path
How to go up one directory first (..?)
What is the syntax to make this work?
First of all, %Temp% might not be the same as %LOCALAPPDATA%\Temp!
The way to create a perfect shortcut to %Temp% is not that easy, ideally the .lnk should only contain a EXP_SZ_LINK:EXP_SZ_LINK_SIG block with the %Temp% string. You have to manually delete the ItemIdList block to get a .lnk file like that. %Temp% is extra complicated because it does not have a special folder canonical name you can use with the shell: protocol.
I don't believe the shell: protocol supports .. nor . path components.
shell:AppData ..\Local is also wrong because the local appdata folder might be somewhere else (< Windows Vista used different names) and a better command would be %windir%\explorer.exe "shell:LocalAppData" (and in turn %windir%\explorer.exe "shell:Local AppData\Temp") but all of those commands have other issues.
First of all, Explorer might not be the users shell and you risk not obeying the users preferences.
Another problem is that a .lnk file contains the attributes of its target and because the link actually points to a .exe file your .lnk file will not have the FILE_ATTRIBUTE_DIRECTORY bit set for its target attribute and the shell will not understand that it points to a folder. A .lnk that points to a folder will sometimes open in the same window when navigating the shell instead of opening a new file browser window.
The .lnk binary format is documented and by breaking the rules a little bit I have been able to create a link that points to a file/folder inside a special shell folder by combining a EXP_SPECIAL_FOLDER block with a manipulated ItemIdList but for whatever reason this trick does not work for deeper paths.
A EXP_SPECIAL_FOLDER block and a empty ItemIdList is the only way to create shortcuts to special folders that is guaranteed to work on all systems but you have to create it manually, the IShellLink implementation adds system specific blocks that might break things if you try to use the link on another system.
The .lnk format has not changed much since Windows 95 and there is simply no easy way to create shortcuts relative to special folders that also work when they are copied to other systems. The relative path string in a .lnk is relative to the .lnk file itself and is not helpful in this case.
I would recommend that you simply create the .lnk on the target system in your installer/application and let IShellLink fill in as much information as possible behind your back.
I have an application that can "serialize" its state as a folder with images. This folder is called, e.g., C:\Temp\MyProject.ImageExplorer and the FileSystem consists of :
C:\Temp\MyProject.ImageExplorer\Pic1.jpeg
C:\Temp\MyProject.ImageExplorer\Pic2.jpeg
...
Can I Configure Windows Explorer in a way, that a Double Click on a folder with my .ImageExplorer "extension" does not open the folder but starts my ImageExplorer.exe with the folder name as command line argument?
Can I modify the C# .Net OpenFile Selector in a way to open these "Folders" including the Filter by extension ?
You can do it but might have issues since the file type is a folder. What I would do is basically make it a uncompressed .ZIP file, You can change the extension to what ever you want so you can associate it with your application like .IZP
You can make your application setup a registry key that associates .IZP with your application and pass the path to the file in as parameter to program.exe path/to/izp/that/user/opened
You might just have to adjust the program to handle reading a container rather than a folder.
I script a lot of things to manage the computers in my company. I often need to add shortcuts into the personnal startup folder of users (without a GPO).
Windows 8/8.1 doesn't have a personnal startup folder by default.
Its location is C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\
It is easy to create this folder, but it needs a desktop.ini file into it, with the correct content, for the name to be localised (else it is displayed "Startup" whatever the language).
What is the "official" way to create this folder?
Or what is the official way to add something into it?
I'd prefer a PowerShell or batch command, but whatever reliable mean is okay.
I guess you can do something with the ComObject for this special folder:
$startup = (New-Object -ComObject Shell.Application).NameSpace(0x07)
By the way, if I enter shell:startup in a run box (Win+R) on my Win 8.1 system, it directs me to my personal startup folder (C:\Users\User\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup).
As far as I know, there is no reliable way to do this.
You can get the path with [environment]::getfolderpath("Startup") but the returned string is empty if the folder was neve created. And I don't know any API entry to create it.
So you have to manually create it:
check if the former command return anything (if yes, just create you shortcut)
create yourself the startup folder. Use [environment]::getfolderpath("StartMenu") and add \startup to the path
then create the desktop.ini file and populate it yourself
and update the registry HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders (I didn't check if this is the right place. [environment]::getfolderpath("Startup") must return the right value)
UPDATE: I just found SHGetKnownFolderPath API which allow to create the required folder if needed (with dwFlags). I'm not good at PowerShell, so I don't know how to call this. Maybe Someone can give a better answer.
I have a type of data file associated with my program. I can run my program by clicking on a shortcut, or by double-clicking on the data file. Standard Windows stuff.
However, I need to be able to set the Starts In folder to a specific folder. Everything is fine when I use the shortcut (because that has a Starts In parameter), but when I double-click on a data file, the Starts In defaults to the local folder of the data file, which is not what I want.
To be more specific, I'm using a network dongle protection system (Safenet SHK) that requires an XML file to be in the Starts In folder before the protection shell allows my code to be run, so I can't just change the folder in my program, because it hasn't run yet.
What can I do?
You could create a launcher application. This application would do nothing but set the working directory and then start the real application and pass in the name of the file the user is trying to open. Your application shortcut can point to your main application, but the file associations you create would use the launcher.
There's an executable file generated from my program in MFC and I want to use it as the default program to open the .jpg files. That is to say, each time I double click a .jpg file, my program will run.
I tried to add some registry entries linking .jpg files with my program, such as HKEY_CLASSES_ROOT\.jpg\shell\open\command (set its value to "myProgram.exe" "%1"), and HKEY_CLASSES_ROOT\myProgram.
The method works just fine except when some other applications register themselves to open the .jpg files. For example, I have installed acdSee on my computer, so each time I doule click a .jpg file, it always start acdSee instead of my own program. But when I register a completely new type of file with my program, it can be open in the program. I don't know how to set my program as the default opening program of an already registered file programmatically. Can anyone help me solve this problem? Thank you very much!
The more typical/standard way for doing this is to set the default value of the ".jpg" key to a name that identifies the file type more clearly, and then setup the various associated actions there. So for jpgs, you might do this:
HKCR\.jpg
#default = MyApp.JpegImage
HKCR\MyApp.JpegImage\shell\open\command
#default = "myApp.exe "%1""
If some other program decides to register the type, they will replace the default value for HKCR.jpg with some other value, like OtherProgram.Jpg. At that point, you could re-register it to your app by setting the value back to MyApp.JpegImage.
Disclaimer: When making this sort of change, please also try to respect the user's preferences. For instance, when installing your application, give the user the option to set this file association or not set it. You can also provide a command from inside your installed application to reset the associations, if the user should wish to do so.
If you instead wanted to add some additional commands to an existing registered type, you would read the default value of the .jpg key to find the name of the file type. Then you could open that key and add an action to the existing set of actions. For instance, you could add the following:
HKCR\ExistingApp.JpegImage\shell\myopen\
#default = "Open with MyApp"
HKCR\ExistingApp.JpegImage\shell\myopen\command\
#default = "myApp.exe "%1""
Note that by writing a key to HKCR, you're actually writing to HKLM\Software\Classes. This will require administrative privileges. However, you can make per-user changes within a user context by writing your keys to HKCU\Classes\Root instead.
Also, user preferences in HKCU will override the system defaults in HKLM, which sounds like what your problem might be.
This is when a program has not registered an extension as a "Default" (Is the program listed in Set Programs and Defaults in the Control Panel?)
Time to start reading documentation!