Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations sizbut on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

User Defined Fields

Status
Not open for further replies.

Imaginecorp

IS-IT--Management
Jan 7, 2007
635
US
In the Real world, emphasis on “Real”, does anybody (clients) ever use or require "User defined fields" any more. In other words is it really worth it to provide the client with the capability of creating some of their own fields? In my experience, 98%+ of our clients have never used this feature... What has your experience been?
I would really appreciate some insight here.
Thanks.
 
I am currently working on a project (HR/Payroll software), that having that feature would be nice, but users or even power users may not have the understanding of the impact of adding a field. We (as programmers) do it for them, much more controlled. I have in the past seen a sofware done in VFP that had that feature, and I nerver asked the vendor if it was a good selling feature. But at the time I thought that was a nice thing to develop. The thing to think about is keeping the core of the application intact and generic, and adding custom fields in a custom folder for specific customers, that takes a little thinking about.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)
 
Hello Mike; we currently have that feature in our application, its quite simple to implement really but a pain in reports...Just that nobody really uses it, not because its complicated but they (our clients) have never had a need for it. But thats the trucking industry...

Was curious about other developers experiences...
 
Imaginecorp,

I've never provided the users with a way of actually adding their own fields to the database - and I wouldn't want to. It would open up all kinds of issues that I'd rather avoid.

However, I have occasionally found it useful to add a small number of user-specific fields, that is, where the fields are always available in the database, but the user decides how they want to use them. The user is also allowed to choose a name for the the fields, but this is only for the user interface -- I don't actually rename the physical fields.

If you adopt that approach, you'll have to consider what data type the user fields should be. You might provide, say, three each of numeric, character and date, or simply make them all character.

On the whole, though, this is not something I do often. Usually, just a simple Notes field (a memo field) meets the users' needs.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk
 
Just my two cents here. I have an application where I let the users add what I call properties to each record on a form. After these are defined a movable / shrinkable control appears on the form. The users can move the control around the form with the mouse or shrink or expand it as desired. This control is a grid of the available properties and their current values. The user can change any of these values just like any other grid and the records are linked to the id of the current table. In the setup of these properties I let the user specify: the display sequence in the grid, the type of field (character, date, numeric, or logical), field length, entry mask, format mask, report label, report width, report alignment, and a list of possible values for a combo box in the grid. When the grid is displayed on the form I set the input mask etc. based on the type of field, etc. and validate accordingly. I also have a class that appears on the report form to let them choose what fields to print. Another class adds the fields to be printed to the report cursor, and yet another class hacks the report when it is run to add the selected fields to the report. I added this feature after I got tired of adding fields to the table that only a few records would ever use. This way they can add most of what they need fairly easily.

Auguy
Northwest Ohio
 
Thanks to all who responded, but I shoule explain...

We already have this feature in our app. Its based on the DBC model.

I am in the process of writing a Brand New application and felt providing UDF capability would be wasted effort based on previous experience.

My question is How many of you provide UDF capability and/or feel, based on your experience, it is a major selling point and your users use this capability consistantly.

Thanks
 
Imaginecorp,

Well, you have several different answers, which I hope you'll find useful.

But, you know, ultimately, the only people that matter are your customers. Given you have an existing application which has this feature, why not ask the existing customers whether they use it. Of course, they might not have the same view as the potential customers for your new app, but at least it will be useful guideline.

Let us know what you decide.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk
 
why not ask the existing customers whether they use it. Of course, they might not have the same view as the potential customers for your new app, but at least it will be useful guideline.

Makes perfect sense, except that only about a handful of our current clients use this feature. The problem I have encountered over the years is whenever you discuss a feature with a potential client; they want it, especially if it’s free, whether they will use it or not is a different story.

The only drawback to this feature in our app is reporting.

All UDFS created ask if they are reportable and what category they belong to i.e. Finance, operations etc. So when, for example, a financial report is generated the app has to determine the number of udfs created, if any, in the financial category then include them in the report. (Figure out placement etc.) It’s just a lot of programming.

I am in two minds, whether I should include it in the new app or not. I probably will only because we have it.
 
Imaginecorp,

The problem I have encountered over the years is whenever you discuss a feature with a potential client; they want it, especially if it's free, whether they will use it or not is a different story.

Yes, I'm sure that's always the case. It's the classic market research problem.

Personally, I'd be inclined not to include this feature, especially if I could put the same effort into some other features which have been definitely requested. But of course I don't know know your app (or your customers) as you do.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top