I have found Bridge CS4 a vast improvement over the CS3 version, I actually use it now. I had to use Bridge 2 to get any work done.
Brandon - I don't have the code handy now. We tried a few different techniques, and in every case the MS code called before our code was leaving the file marked as busy. Basically, it's a bug we can't work around.
Chris - There aren't any known bugs like that in Explorer, and we'd surely know about them if there were (after all, the dozens of in-box thumbnail handlers use the same APIs, as do Office and countless other third parties).
Most likely a bug in your code was leaking something that caused the behavior you saw. The pre-Vista API for providing thumbnails (IExtractImage) was a bit less than straight-forward so I'm not surprised that some developers ran into issues getting it working properly.
However, in Vista the new IThumbnailProvider API is extremely simple and very easy to implement, with some great samples available in the Windows SDK and easy to follow tutorials on MSDN. It even supports out-of-proc implementations so you don't have to worry about destabilizing the shell and can even write them in .NET.
Details about building a thumbnail provider can be found here: http://msdn.microsoft.com/en-us/library/cc144118(VS.85).aspx
If you have an implementation that appears to be causing problems with file locking and such, please let me know. It would be very helpful to share that with my team so we can figure out what the cause of your problem is.
Can't say fairer than that!
Brandon, I was about to say 'why weren't you around here when Photoshop 7
was out?' but after looking at the picture on your blog you probably weren't
even alive ;)
Brandon - the bugs are still outstanding with Microsoft, but we've stopped pressing for fixes and moved on. Other apps have seen the same bugs, with completely independent implementations - which is why other apps have also dropped their thumbnailing explorer extensions (or continue to live with "file is busy or in use", which you still see from the MS provided thumbnailers).
And we have to write code to support XP and Vista, so we can't use just the latest Vista APIs (assuming they worked correctly, but they don't).
Chris - I work on the Explorer team. If you have a specific bug to report please do so, but none of the in-box handlers have such problems, and none of the APIs have known issues. Repeating that claim won't make it true!
As part of the Windows 7 Beta SDK release we're doing a big push to get developers with file formats to implement a complete set of format handlers. That includes things like thumbnail handlers, preview handlers, property handlers, and IFilters (for files with textual content). The Win7 Beta SDK will include a tool we demo'd at PDC that will run a series of tests against your file format's handlers and report what is missing or where common issues/bugs are found. This tool might be of help to you in ensuring a great experience for your Windows users working with your file formats like PSD.
As I said, we'd love to have Adobe provide a full set of handlers including thumbnails for PSD. In fact, in Vista or later you don't even need to implement a thumbnail handler, you can have a property handler that returns the thumbnail via the PKEY_Thumbnail property. If your format already includes a lower-res thumbnail image embedded in it, it can't get much easier than that.
Now if you don't want to or don't have the time to implement proper support for your format, that's your call. And while I know you probably have lots of users running XP and will for a while still, I'm betting your Vista and Win7 users would be grateful if you added such support using one of the Vista mechanisms.
As an Explorer team man please reveal how we can get the size and view settings of Explorer Windows to stick permanently. Nothing seems to work; not even clicking the close [X] button with modifier keys. And it's just as bad in Vista!
Edit: Sorry for the OT excursion, this has bugged me since Windows 3.0. :(
On Vista and XP, window sizes are stored on a per-folder basis. So if you open Computer, resize it, and then close it - it should be the same size when you open it again. But if you open Documents, that may be a different size (the size you last closed Documents at, or the default). Modifier keys have never done anything special when pressing the close button - no idea where that rumor got started.
There's also been a bug for a while that could cause Explorer to "forget" view settings for some folders, basically a corruption bug in the persisted settings data. We finally were able to track this down and made a fix for this in Vista SP2 (and Win7).
Also, the Explorer window size behavior seems to have changed for Win7, as the Explorer now opens at the last size and position it was closed at, no matter what folder location you open to.
> There's also been a bug for a while that could cause Explorer to "forget" view settings for some folders, basically a corruption bug in the persisted settings data.
That's the one! Thanks for replying anyway Brandon.
I just want to add my voice to the thanks to Brandon for popping in
here. It's good to have a MS insider providing some info.
Don't be a stranger.
I'm sorry, but I have to add my two cents. Reading this current exchange, It seems that we have a Microsoft team member who is willing to help (almost bend over backwards) and the Adobe team member who seems to be very resistant. I would hope that isn't the pervasive philosophy within the Adobe team.
Thank you Brandon for joining in.
Yes, let's dig the old bug reports! Hope that they are still available with Red Wednesday... my thoughts are with those that got pinkslipped. I hope that the Photoshop team did not suffer too much, but it is very selfish...
Brandon - I'll have to follow up with our Microsoft liason. We've got a long list of bugs still open with MS and I don't know the specific issue number for that bug.
Paul - we would help if the API worked, but as far as we know it still doesn't work. Somewhere Microsoft may have failed to communicate a bug fix status to Adobe, and maybe Adobe isn't regressing every one of the hundreds of bugs we have open with Microsoft with every build of the OS. Both parties want to do the right thing, but somewhere communication broke down. You could also view this discussion as: Adobe tested this, found crippling bugs, reported the bugs to Microsoft, Microsoft didn't fix the bugs and Microsoft now claims the bugs don't exist. It depends on the viewpoint and what information you have available.
> I'm sorry, but I have to add my two cents. Reading this current exchange, It seems that we have a Microsoft team member who is willing to help (almost bend over backwards) and the Adobe team member who seems to be very resistant. I would hope that isn't the pervasive philosophy within the Adobe team.
> Thank you Brandon for joining in.
Got the same impression. Couldn't have said it any better!
At the moment we got this (Adobe left, MS right):
Let's hope it will end like this:
And not like this (MS left, Adobe right):
>I've just been looking for an excuse to post the gif...
stolen! MUWAHAHAHAHA! :)
Who is your contact for the Explorer team? Our platform program manager, David Washington, is probably the best person to talk to. If you (or the approriate person on your side) would like to get in touch with him, you can drop me an e-mail any time and I'll make the appropriate introduction. You can reach me at Brandon.Paddock@microsoft.com
As for your past experiences dealing with the Windows team I really can't comment especially without knowing what channel you'd gone through or who was around back then. All I can do is try to help with any problems you're hitting *now* and connect you with the best people to address any problems you run into.
Our team is extremely aggressive about fixing any issues that block adoption of our platform from ISVs, and large ones like Adobe in particular. If there really is a bug preventing you guys from implementing format handlers, I don't believe it would be hard for us to ensure it is fixed in Windows 7, and if at all possible I'm sure we'd do everything we can to get the fix available downlevel (ie. service pack, etc).
That said, the sheer number of thumbnail handlers that currently work on Vista without problems, and the in-depth test coverage we have in this area, makes me quite certain we could help you get this working without any changes to the OS at all.
You have my e-mail, so if you would like to try and get this feature working for a future Adobe release, please drop me a line at your convenience.
I will take care of this: What type of beer do you drink?
See, that was easy. :)
On to the next part.
We don't have a contact on the explorer team itself, we have corporate liasons between our companies.
According to our status of bugs filed with Microsoft: the explorer extension "leaving files open" bug still is not fixed, but the bug report has not been updated in years. (which is part of why we gave up hope that it would ever be fixed)
Someone will be in touch.
Based on the registry setting, it looks like psicon.dll implements IExtractImage.
IExtractImage::GetLocation is passed a name to a file. The shell doesn't open the file, nor does it close it.
There is most likely a disagreement about the lifetime of the IExtractImage object and when the file should be opened or closed.
The simple workaround is to grab the thumbnail in GetLocation and close the file, or use a lazy load and open/close the file in IExtractImage::Extract. You would only need to open the file for a miniscule amount of time and close it right away.
When I implemented IThumbnailProvider for DNG, I used similar logic in my implementation of IInitializeWithFile -- request late and release early -- to avoid issues like this. This doesn't give you the flexibility of IInitializeWithStream, but it does give you total control of the lifetime of the file handle.
Yeah that's pretty much what I was saying in my original post :)
IInitializeWithStream is preferred for most handlers, though. It lets the handler operate over non-file objects, like files in a Zip folder, or any other namespace location that supports returning an IStream for its items. This will becomes more important going forward as we move more and more toward browsing and searching remote data, like OpenSearch locations in Windows 7.
In many cases we can create temp files to get around this (which is what Win7 does for OpenSearch locations with file-based previewers and such), but direct stream handling is preferred. We require it starting in Vista for IFilters because we lock down the filter host process so tightly that it *can't* access the file system, and so it can't mess up file access.
Previewers are another case where we prefer to host them at Low IL (like IE does with its protected mode tab processes), and if you let the shell handle getting the stream we can use very fine-grained oplocks to ensure that file access is never interrupted or blocked for other applications, merely delayed, while the file is being loaded.
So yeah, IInitializeWithStream is the best initialization pattern for a new handler as it allows you to take advantage of the many benefits of shell abstraction layer :)
Hey Brandon, could you help me with this? Or anyone else, every bit of help is welcome.
I'm trying to implement thumbnail provider for swf (flash) files in C#, but can't get IInitializeWithFile to work. It just won't call Initialize. IInitializeWithStream works fine, but I'd really like to get the path (because swf might load external files and I can't know where to look if I'm using stream)
I've seen on couple of other forums that people have the same problem and nobody got it to work.
Here's a piece of code:
//works fine, I get the thumbnail
[ComVisible(true), Guid("b824b49d-22ac-4161-ac8a-9916e8fa3f7f"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IInitializeWithStream
void Initialize(IStream stream, int grfMode);
//doesn't work when I implement it
[ComVisible(true), Guid("b7d14566-0509-4cce-a71f-0a554233bd9b"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IInitializeWithFile
void Initialize([MarshalAs(UnmanagedType.LPWStr)] string pszFilePath, int grfMode);
For the first parameter I've tried every type that came to my mind, but couldn't get it to work.
These questions are a bit of a thread hijack. To bring this back to the original subject, the most frequent request we get is to do a PSD WIC codec. We have just started on it, but we should have one out in both 32 bit and 64 bit flavors in Q1 of 2009.
If you're not a software developer, then you can ignore the rest of my post.
If you implement IInitializeWithStream, then IInitializeWithFile won't be called due to the precedence stated in the remarks for IThumbnailProvider.
Also, both the Shell team and the .NET CLR team discourage writing shell extensions in managed code. See the comments from folks on both teams at Microsoft on the following link.
Thumbnail providers are sort of exception, they run in their own process so it's ok to write them in managed code.
I know that IInitializeWithStream has precedence, I comment it out and leave only IInitializeWithFile, and then it does nothing. dll is called but just won't call Initialize, it just exits like there's no appropriate implementation of IInitializeWithFile.Initialize
Sorry for thread hijack but this is sort of the only chance to resolve this thing once and for all, even if it means that it can't be done. I'm on this two weeks already and I've seen that other people also have the same problem. The one thing I didn't try is to make Preview handler, because it also uses IInitializeWithFile, and it seems to be working for other people who messed with it in C#, which makes it even more weird.
Bump, this is the thread where I was wondering if communication was working again... Mr Hamburg might know about the bug, too, and works in User Exeperience...
This exchange is the equivalent of New York politicians calling Chicago politicians "corrupt."
Adobe in infamous for being uncooperative and difficult. Whichever supervisor let this Adobe kid post these unsupervised rude responses to the Microsoft fellow should be canned -- unfortunately, it'll take Adobe three years to be able to evaluate this situation.
Microsoft and Adobe users don't give a darn about your little bickering -- what we want is software that makes life easier -- that we don't have to think about. I don't use Photoshop so I can think about Adobe stuff -- I use it to create images.
I paid a fortune to Adobe for Photoshop. The ball is in Adobe's court -- fix it!
Why are you telling us? We are users.
And the "Adobe kid" is probably twice your age and, even if he evades the confrontation witn M$, at least he is civil.
Photoshop CS4 works fine for the vast majority of users. It's just a few unfortunates that post here with their problems.
BTW, I too think this thumbnail problem could be solved if people got their fingers out.
I think that this discussion misses one of the big issues with no psd thumbnails in Vista OS. If you use Lightroom 2 to import images that are on a drive you cannot see what the psd images are without leaving and using bridge or a better program like Irfanview. Talk about an albatross around your workflow neck.
Now I'm excited. FINALLY! Someone is actually doing something about the icon in the .psd format.
It's much easier to view your icons in explorer than to launch Bridge. I don't care how fast Bridge is,
it's a program that needs to be started vs. just looking at the icon in explorer.
You still have to open explorer in order to view and wait for it to populate. Just like opening bridge up by itself, view and pick what you want, or just double click on it and it opens in CS4 64 bit or 32 bit whatever you choose.
Still it is nice someone is working on the explorer part though and it working in 64 bit more will be sweeter.
You still have to open explorer in order to view and wait for it to populate.
Aw come on – there's no comparison!
Well, we both already know that.
I was just focusing on the fact that explorer still has to be opened in order to view thus there are no step savings.
I use PowerDesk, it has .psd thumbnail support, was using it before Bridge happened along.
I checked their website and it does not Vista 64 bit. Vista64.com has a link to xyplorer (for example) and it works in windows Vista/7 64 bit, does not replace explorer but works along side. $16.00 cheaper too. Not that I am in the market for such software. Just you sparked my interest to research further. There are a few others out there too.
I have Vista 64bit and it works just fine.
I use Power Desk's Dialog Helper every day.