I was in need of an option to add User Defined Fields to the catalog, so I decided to do it myself.
I thought that maybe some of you guys might find it an interesting feature to have, so I decided to put it up for download. Here it is: Patch.zip.
You need to apply it to the source code and re-compile.
I added scripting support through 2 new functions that you can call from your script:
Code: Select all
SetUDField(name: string; value: string);
GetUDField(name: string): string;
I also added support for export. You add in the export template something like this:
Code: Select all
$$ITEM_USERDEFINEDFIELD(My Field)
I also added a "rudimentary"
GUI for manually adding and modifying user defined fields (UDFs). You can find a button on the main frame, that leads you to a poorly-designed dialog for this purpose. It doesn't have language support (only english for now 
).You can define specific fields for specific movies (no restrictions there). However, the true power (and usability) of this option comes into hand when you define the same UDF for every movie in the catalog (such as importing more stuff from an online provider into your defined fields). In this way, you could make exports, and all kind of stuff with your fields. There is no limit to the number of UDF you can define for movies ( maybe 65.536, but you won't get there
).You don't need to manually add the UDF to each movie from the GUI. You simply modify your script, and if the script wishes to set the value for a UDF that is not defined yet, it automatically creates it for that movie. Oh, and remember to back-up you catalogs before using this feature. I didn't have problems with it, bu who knows? :P
Please note that these fields work only for XML catalogs. If you save your catalog in AMC format, you lose all defined UDFs. An EXE compiled with this code should have no problem loading catalogs w/o UDFs, and also, a normal build should have no problems loading a catalog that has UDFs (just that it won't know how to read them).
Ok, I already made this text too long. If you guys will find this an interesting option, I will surely invest more of my time to making it clean and more appealing. I won't however be able to (easily) add support for the standard .AMC file format, because it's a fixed-length-record file, binary, so not much I can do about that.
Anyway, enjoy. If antp finds this interesting, I have no problem with him making a build (EXE), or integrating with his sources for you guys to look at it. I would make it myself, but my files are way too stripped, you wouldn't like what I made of it
(no reporting, no printing, etc), and plus, I don't know the legal consequences of me distributing a compiled .EXE of the application.
