![]() This also makes things a lot easier for those times when you need to pass a NULL reference to a method or function. I allocate the memory for the IntPtr when required using Marshal.CoTaskMemAlloc, and tend to free it either immediately if it's not likely to be reused very often, or during the object's Dispose method in the case of the PropVariant and PropertyKey objects that are passed around like a fifth of Jack at a frat party. As a result, most of the time when you look at a function or method declaration in the code, where a PROPVARIANT, REFIID, PROPERTYKEY or Interface object is required, either or, you will see an IntPtr being passed instead. It is a similar story with the PROPERTYKEY and PROPVARIANT structures, the latter of which is very similar to a normal VARIANT, but is dissimilar enough that if it gets marshalled to an object, an exception can be thrown. So, I created my own GUID object, marshalling the value into unmanaged memory myself - and it seems to have sorted the issues. For instance, when passing a reference to a Guid, some methods insisted on:Ĭopy Code Guid riidĪnd I found often if you used the wrong marshaller, then you would either get a critical Memory Access Exception, or some really strange result (one of the calls was even changing the value of the Guid). Due to the complexity of the marshalling (and perhaps bugs in the system - I don't know), I found that the automatic marshalling process didn't quite get it right all of the time, and was inconsistent in the way it expected the marshalling to occur. One thing I have done in this library is to take on board a good deal of the marshalling of structures and interfaces. I will go through these objects one at a time. The names of these mirror the interfaces and structures exposed by the Windows Property System, but are tidied up for ease of use in the. There are two basic objects used for the identification and valuing of a property, and then three main objects that provide access to the system to retrieve and/or set the properties. I felt it much better for the code to be able to prompt the user either before or during the save process, and perhaps even set some of that metadata itself, without the need for user interaction. The Properties window is only available after the file has been written, and I felt that was like putting major data collection process into the clean-up. I am currently working on another class library that involves saving files, and I wanted to be able to gather and set appropriate metadata about the file, and write it as the file was being saved. NET application, and the second reason is that during the course of researching and writing this, I did find a number of bugs in the system, which I have managed to code around. I did it this way for two reasons firstly the declaration of the interfaces and functions are not very friendly for a. The code in this class library encapsulates the internal interfaces and functions, rather than exposing them directly. For example, there are properties that read/write from the ID3 tags in audio and video files, or EXIF data in photographs, or authoring data in documents, be they open XML or proprietary formats. The beauty of this system is it allows you to edit metadata in a multitude of file formats without having to know that format. The most recognisable part of the system is probably when you select Properties in the context menu for a file - the metadata that is displayed in those pages are all part of the Windows Property System. This article targets the properties available in the Windows Shell, but the information here could quite easily be reused for any other part of the system. These areas may be devices, windows, the file system, and more. The Windows Property System provides common interfaces for accessing metadata referencing various areas of the Windows operating system.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |