At the moment the only option is to pass a folder name (or file name) on the command-line, and the program will load the folder in question, or the file and all its siblings. Depending on preference options, the program will also load any images in sub-folders (this is the default behavior).
There is no mechanism to pass a custom list of images to FastPictureViewer at this time. I've considered adding such a mechanism previously, to open Explorer's search results when clicking an image that was part of a search result set, but I did not find a way to get access to the search results which seems to be internal to the shell, so I did not implement the mechanism in question in FPV.
You could fake something using hard links: create a dummy folder, say "SearchResults", and populate it with hard links pointing to the real images. To experiment with hard links, FSUtil.exe is your friend:
- Code: Select all
fsutil hardlink create "C:\SearchResults\img1.jpg "C:\SomePathname\SomeImage.jpg"
Your application only needs to manage the content of the SearchResults folder (clean it, populate it with current search results...) then launch FPV on this folder.
This will do what you want with some restrictions (from the top of my head):
- All files must live on the same volume.
- Deleting/renaming a file from FPV will only delete/rename the hard link, not the actual file.
- Rating in FPV will rate the original file if the format is JPEG, TIFF or HD Photo and XMP embedding is enabled, but if the program is configured to create XMP sidecar files (as when rating raw files) the sidecars will be created in your SearchResults folder, with the same base name as the one you used when creating the image's hard link.
You can probably get around most of this by careful management of the SearchResults folder, for example you could detect deletions and delete the originals. You could also create hard-links to existing sidecars (so the program will update the original sidecars when rating) and detect then move back newly created sidecars.
With some (seemingly reasonable) work, the only limitation that might remain is the “same volume” restriction, as hard-links cannot point to files on a different volume. But then there are junctions (reparse points) and symbolic links, where you can mount a volume within a folder or join folders from different volumes, so there is probably some way to work around that last issue too.
I'm sure you can hack together something basic in a half hour or less. Then if you see it works for you, you can tackle the special cases described above (you may find more special cases along the way).
Besides FSUtil.exe, you can create hard links using the straightforward
CreateHardLink() Win32 API function.