Adding Custom Properties

Oct 11, 2013 at 6:55 PM
Hi,

I am using version 1.1. Selecting one file extension, it seems I must select one of the 2 profiles of editable properties. It seems, then, that I cannot just add custom properties at will (outside of a given profile). And it seems I cannot create my own profile of editable properties.

Am I right? Am I missing something?

Thank you.
Coordinator
Oct 11, 2013 at 8:23 PM
Hi Iodimas

No, you are quite right.

I did originally think about allowing users to create custom profiles. The File Association Manager in the Beta version even went as far as showing all the installed properties in a panel (600+ on a typical Windows machine) so that in a later version they could be dragged onto a profile to customise it.

However, the feedback I got (e.g. http://www.downloadcrew.com/article/30413-file_metadata_10_beta_64-bit) was that the resulting UI was too complex, and so I simplified it for the 1.0 version.

I don't think that I would go back on that now, but I could imagine a separate 'Advanced File Association Manager' with a full profile editing capability. Do you think that such a thing would be broadly useful?

BTW If anybody else wants to chime in here, feel free.

Dijji
Oct 14, 2013 at 8:18 AM
Hi Dijji,

If I understood properly, it seems that, in the beta version, you could choose from a set of already installed properties. But, could you create your own properties. I really think that it would be great to have and Advance option where you could:

1.- Create your own of properties.
2.- To group them in custom namespaces.
3.- The group again them in profiles.
4.- To associate to a file either properties one by one, all in a namespace, or all in a profle.

Why do I need it? I think Windows Explorer, although maybe not perfect, it's quite good and powerful, and far more advanced that other file system browsers in Windows and other platforms (not being able to handle properly > 256 paths might be it's only real limitation). Having lots of documents and books, I dislike needing to have a dedicated software to manage them, as I think Windows Explorer does the trick with a proper way to handle and manage meta properties. This way, I don't need to duplicate management efforts (file system + dedicated software). As I want to use Windows Explorer as my books library, I want to be able to have my own properties as, for instance, when I read it, how many times did I read it, when I am planing to read it, etc. I don't want to be tied to pre-existing properties that might not suit my needs.

I would really love to be able to help you, but Windows programming is not my forte.

What do you think about all these things?

Thank you.

Dimas
Oct 14, 2013 at 8:50 AM
Hi Dijji,

It seems that this project is working in the same direction than you, and maybe you could join efforts:

https://wpsedit.codeplex.com/

Best!

Dimas
Oct 14, 2013 at 11:08 AM
Hi Dijji,

Sorry for being off-topic, but I've got a problem that took me some time to figure out. If you add a profile (let's say, Office DSOFile) to a given extension (xlsx in my case) and then I remove it, I Can still see the properties of this file extension in Windows Explorer (bottom panel), I can edit them, but then I get an error when saving. If I save properties opening the excel file, they are not visible in the bottom panel. Adding the profile again fixes the problem.

In any case, I think it would be a nice feature being able to safely rolling back an action, reassigning the previous status of an extension, even after a long time. What do you think about this?

I am getting excited about how useful and powerful your utility could be...

Best!

Dimas
Coordinator
Oct 14, 2013 at 1:00 PM
Hi Dimas

I will try to explain how the pieces you will need fit together. There are three important aspects: defining properties, storage of properties associated with a file, and editing properties.

a) Property definitions

Windows comes with a whole set of property definitions. There are more than 600 of them, listed here: http://msdn.microsoft.com/en-us/library/dd561977(v=VS.85).aspx. You can define custom properties, too. Once defined, they are equal citizens with the system-defined properties. However, defining them is not that straightforward, you need to register them and provide a lot of information. Here, for example, is the definition for the System.Keywords property:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb787519(v=vs.85).aspx

Looking through the predefined system properties, I don't see anything that will meet your needs, so I think that the first piece you will need is a custom property editor. I don't actually know of one, but if you find a good one, do let me know.

b) Property storage

Once the properties that you need have been defined, and you want to apply them to a file, you need to consider how they will be stored. The Windows property system uses 'property handlers' to read and write property values. A property handler must be registered for each file type (i.e. extension) with editable properties. Windows comes with built-in property handlers for file types like Office documents and jpeg. However, since these property handlers store the properties within the files, they can only read and write properties that can be mapped onto some storage location in the file format. This goes for third-party property handlers too: for instance, one well-known property handler for PDF files will write tags, but not comment, because PDF files do not have a well-defined locations for comment. It follows that custom properties are going to present particular problems.

One solution is to use File Meta, which will store any property, including custom properties, against any file type. It works this trick by storing the properties in an annex to the file rather than in the file itself, so that it is independent of the file format.

c) Property editing.

The last piece needed is a user interface to edit the properties. File Meta uses Windows Explorer to do this. WPSEdit is an alternative editor. It does not address the problems of custom property definition or property storage.

File Meta tells Explorer which properties to display for which file type through registry settings that are manipulated using the File Association Manager, grouping the properties in profiles. The beta version did not allow the creation of custom profiles, it merely displayed the set of properties defined on the system, but didn't let you do anything with them. If your custom properties were already defined, then they would be shown too.

As I said in my previous reply, it would be feasible to extend the File Association Manager to support custom profiles. However, this would be of no use to you unless you also have a way to define the custom properties that you need.

So, in conclusion, if you can find a custom property definition tool that suits your needs, let me know, and I can look at extending the File Association Manager to support custom profiles. File Meta can already help you store the properties. Alternatively, you can switch on your custom properties in Explorer with a few relatively simple registry edits, or use an alternative property editor such as WPSEdit.

I hope this makes things clearer. Do let me know how you get on.

Dijji
Coordinator
Oct 14, 2013 at 1:32 PM
Hi again Dimas

You see this rather odd behaviour because Explorer caches the registry settings when it reads them.

So, when you remove .xlsx in the File Association Manager, the registry settings are updated appropriately, but Explorer does not reread them, and still shows the properties as being editable. However, when it tries to write their values, this fails, because the property handler has been removed from the registry, and the property system cannot create an instance of it to write the properties.

This is not a beautiful thing. However, I don't know, at the moment, of any way of forcing Explorer to reread the registry other than killing all instances of it and restarting it.

I don't think that rollback addresses this problem, because it arises when the state of registry is out of sync with the state of Explorer, so rolling back registry changes won't actually do much to help, unless you happen to arrive at the state that matches the in memory state in Explorer, and I don't see how you would know when this was true.

If I was thinking of doing rollback, I think I would have the File Association Manager capture the state of the settings for a file extension when it first encountered it, and give the user the option to rollback to them at any subsequent time. But since, at the moment, the File Association Manager only allows you to change the settings for a file extension with no property handler, the initial state is always the empty state, and so rollback would be identical to remove handler. If I ever allow existing property handler settings to be overwritten, then I think rollback would be important.

Dijji