Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[topgunn]

I was defining a custom field for my music libraries.  When doing so I noticed what appear to be a couple of deficiencies in this capability.

First a field identified as an integer field (...-3,-2,-1,0,1,2,3...) can only contian the counting numbers (1,2,3...).  This was identified in my previous post.

Secondly, When defining a custom library field it is possible to define it as either a string, decimal, integer, percentage or list value.  Also you can identify the possible values for any of these fields by supplying a semi-colon delimited list of acceptable values (in the "List:" field).  For string, integer or list fields where the possible values number from, say, one to twenty, this is an excellent approach.  However this approach is inadequate for, 1. fields where the number of possible values is large and, 2. fields identified a containing decimal values which are by there very nature continous.  In both of these cases it would be a vast improvement if the "List:" field could contain a range of values (e.g. for integer fields, 1-100, or for real fields the identifying range could be as, 1.0-100.0)  This would allow for entry of a value from an extensive range but at the same time provide protection against entry of illegal values.

Are these candidates for an enhancement for a future version?

[jgreen]

I agree with the previous post, or at least the parts I think I understand.  From my perspective, MC's handling of rnages is a good start but needs more work.  Date / timestamps and VBR bitrates are fields that come to mind which take on a life of their own currently.