2007-09-30 19:50:26.073346+00 by Dan Lyke 1 comments
Software hates for the day:
link element.[ related topics: Microsoft Software Engineering moron ]
comments in ascending chronological order (reverse):
#Comment Re: made: 2007-09-30 19:50:50.998991+00 by: Dan Lyke
It's quite simple, to do this you create an object type which
implements the IExtractImage and one method of the
IPersistFile interfaces, register it with the file
extension in the registry, and, poof, you should get thumbnails when
users browse directories with your files in them.
So the first thing to do is to create a COM object. COM is a mechanism for taking a relatively simple concept, dynamically linked shared libaries, and complexifying the hell out of their interface. In fairness, it does some cool things, like telling you what their API is so that you can integrate shared objects into scripting applications and explore their interface via automated tools. So if you have a DLL file, you can point a tool to it and say "show me how I can use this!".
Anyone know a tool that'll do that?
But then... every COM class has a couple of incomprehensible long
numbers called GUIDs associated with them. So although the interfaces
have relatively comprehensible names, we quickly replace those names
with things that look like
{FC9850E3-9FC3-4C1F-8EE7-28F51EC014E1}.
Needless to say, the methods for creating COM objects has "evolved" over the years, apparently the state of the art now is to use a combination of C++ classes and preprocessor objects called "ATL". ATL is now at version 7, which corresponds to roughly 6 external releases, each subtly changing the interface from previous releases.
I have Microsoft Visual Studio .NET 2003. The aforementioned articles are from 2002 and 2000. So the first thing I have to do is to make them compile correctly, but, of course, since I've got a 4 year old version of the development environment, it seems like none of the documentation matches my released version.
But eventually we get something that we think is compiled correctly. The older simpler example doesn't compile because not all of the source code is available on the web, but the newer more complex one appears to. We even think that the registry knows how to find the objects correctly, because the (automatically converted) versions of the development environment "project" / "solution" / whatever files are inserting registry entries in the right place.
So, now we need to go make the association between file extension and this object. To do this, we go to HKEY_CLASSES_ROOT, and find the (for the sake of these examples) .SCB file extension. We see from the documetnation that there's either supposed to be an entry under this under "ShellEx" called "{BB2E617C-0920-11d1-9A0B-00C04FC2D6C1}". Most registry entries are case insensitive, some refer to the former as "Shellex", every document I can find about that latter long string of numbers has the lower case "d". I don't question what I don't understand.
But the documents disagree, because .SCB also points to something called "Scribble.Document", so we may make this same entry over there.
And then it's not clear which of the two GUIDs I have associated this object I should be putting in there, so I try both of them.
Rebooting in between each one, because you never know what Windows Explorer might cache.
Nothing.
All I want to do is write the implementation for 3 simple functions, one of which tells me which file I'm going to be previewing, one of which tells me what the format of the preview should be, and one of which asks for the preview. Should take me 3, maybe 4 hours, tops. I'm nine or ten hours into this mess, learning about crap deep insdie Widnows that'd make H.P. Lovecraft shudder in terror, I know that once I figure this stuff out I'll have both the "oh, that works" moment and the "I wasted how many hours of my life on...?" feeling of utter despair that accompanies any attempt to develop for Windows.
And I'm just filled with loathing and hate.
We will not edit your comments. However, we may delete your comments, or cause them to be hidden behind another link, if we feel they detract from the conversation. Commercial plugs are fine, if they are relevant to the conversation, and if you don't try to pretend to be a consumer. Annoying endorsements will be deleted if you're lucky, if you're not a whole bunch of people smarter and more articulate than you will ridicule you, and we will leave such ridicule in place.
Connectivity provided by highertech.net , awesome bandwidth, well away from fault lines and other potential for natural disasters, reliable, and run by cool people.
Questions, comments, flames: contact Dan Lyke
Flutterby™ is a trademark claimed by
Dan Lyke for the web publications at www.flutterby.com and www.flutterby.net.