Just a thought: you might want to look into an Entity-Attribute-Value data model, which (with a fair amount of work on your end) potentially allows users to define and populate fields. You could display those fields in a portal. Different form controls for different user fields are probably not in the offing, however. You wouldn't have to go completely EAV; use a more standard, normalized schema for your fixed fields, and an EAV model for the user-defined ones. I would imagine that reporting gets more complex with this kind of design (especially the hybrid approach), so you'd have to weigh the trade-offs.
Thanks Mark -
I agree about using portal display fields. Question that I am stumbled upon is - once I have a record of field control attributes (field name, label, control type, vvl) how would I make FileMaker display specific control type without going into design mode in my app. It should work as long as I only use a simple text control for everything. As I write I am thinking maybe hiding all control types into portal would work, and a specific field value could work as a trigger to display specific control type in each row.
Re "Can we allow dynamic customization to our FMGo application forms withut opening them in FileMaker Pro?", I don't believe it is posible to create DB fields in FMGo.
Question that I am stumbled upon is - once I have a record of field control attributes (field name, label, control type, vvl) how would I make FileMaker display specific control type without going into design mode in my app.
Instead of using a text field for everything, you could make a field for each type you support, e.g. UserField_Text, UserField_Number, UserField_Date.
Use the new "Hide object when" feature in FileMaker Pro 13 (Inspector --> Data --> Behavior) to display only one field at a time based on your user's field type choice. Be sure to check the box for "Apply in Find mode" to keep the user's interface consistent.
After their behavior is customized, stack them one on top of another on the layout.
There you go, Raj. Tom's suggestion is the way to make this work with multiple field-control types. Another fine use for "Hide object when."
Mind you, because, in the EAV model, these user-defined fields and their values exist as rows in a related table, rather than as columns in the current table, you're not going to be able to easily export or print the values as columns in the traditional sense (at least not without a lot of work). FileMaker doesn't have a built-in cross-tab functionality, and, while their are a number of ways to turn rows into columns, most of the methods I've seen over the years depend on a pre-defined schema, rather than an open-ended one like this. Of course, if printing and exporting are not important to your goals, then the issue is moot.
Let us know how this progresses for you.
Thanks Mark and Tom. Looking back at it, this issue started with FM v12 when Hide object option was not available. Getting hold of questions in row format is not a problem since our SQL Server db already has it in that format. I have tested it in a simple solution. It works well. See attached.
It works well on FM Go, except the calendar control. Because the field type is text, FMGo offers default keyboard entry, instead of calendar entry. It works fine on desktop.
FileMaker community rocks!!
DynamicQcontrols.fmp12.zip 73.1 K