 | |
#11
 
| |||
| |||
|
Re: Insert a record -
10-25-2011
, 03:10 PM
|
In article yourname-2510111614390001 (AT) 203-1...dyn.ihug.co.nz>, yourname (AT) yourisp (DOT) com (Your Name) wrote: In article <yourname-2510111326270001 (AT) 203-118-185-196 (DOT) dsl.dyn.ihug.co.nz>, yourname (AT) yourisp (DOT) com (Your Name) wrote: In article <ws21-0B7E21.13214124102011 (AT) newsstand (DOT) cit.cornell.edu>, Bill Steele <ws21 (AT) cornell (DOT) edu> wrote: Want to use the table as the source for a value list, where the dropdown list will display items in an arbitrary order determined by business decisions (i.e., what the boss wants). The order of the options in a Value List is determined by the Value List definition, not the order of the records within the Table. Taking a Value List from a Field (one field) will sort the options in alphanumeric order. To sort them into a different order you'll need to use a second field and set-up the Value List definition to use that as the sort order. For example if the Table contains Fields with data: Fred Barney Betty Wilma BamBam Peebles Then the Value List will display as BamBam Barney Betty Fred Peebles Wilma If you add a second field to the Table and Value List definition, you can have them displayed in whatever order you want by setting the new second field to have data in your desired numerical order. e.g. by gender, grouped by Flintstone family first and Rubble family second 01 Peebles 02 Wilma 03 Betty 04 BamBam 05 Fred 06 Barney Of course, you don't HAVE to add a second Field. You could just alter the data in the original Field to have the number prefixes and get the same result, although you may then need a new Calculation field somewhere along the line to remove the prefixes for reports, etc. Helpful Harry  )Well, what I have so far is a value list taken from a repeating field, and the value list *does* adopt the order of the items in the field. What I need is a way to make it easy for a user to change the order. The ideal would be something like the Filemaker script editor, where you can grab a line and move it up or down. (Can that be done in the Xcode interface builder?) |
Don't use Repeating fields - you're most likely setting yourself up for
bigger problems at later stages.
You could hard code the Value List and give users access to the Edit
window, but that can cause problems if you've got "novice" users.
)You should really use a separate Table with one record per option. The
options can then easily be re-orderd by simply changing the data in the
second numerical Field either manually or for those "novice" users have a
Script / buttons to make 1000% sure order numbers are not doubled up.
Adding new value is of course easy. This is also where re-sorting the
records comes in from people's previous replies.
If you insist on continuing to use Repeating fields, then you can set-up a
similar Script and buttons system to allow users to move data up and down
and add new values, but it's more cmplicated.
Helpful Harry
)
#12
| |||
| |||
|
|
Well, what I have so far is a value list taken from a repeating field, and the value list *does* adopt the order of the items in the field. What I need is a way to make it easy for a user to change the order. The ideal would be something like the Filemaker script editor, where you can grab a line and move it up or down. (Can that be done in the Xcode interface builder?) |
Do not use repeating fields. They are hammer and chisel technology, and
break first normal form.
#13
| |||
| |||
|
|
On 26/10/11 5:30 AM, Bill Steele wrote: Well, what I have so far is a value list taken from a repeating field, and the value list *does* adopt the order of the items in the field. What I need is a way to make it easy for a user to change the order. The ideal would be something like the Filemaker script editor, where you can grab a line and move it up or down. (Can that be done in the Xcode interface builder?) Do not use repeating fields. They are hammer and chisel technology, and break first normal form. |
#14
| |||
| |||
|
|
Do not use repeating fields. They are hammer and chisel technology, and break first normal form. There is nothing remotely relational about this application. |
There would be if the data dumped into repeat fields was structured into
a related table as it should be. Bad technique, is bad technique. It
doesn't matter how simple the database is.
#15
| |||
| |||
|
|
Do not use repeating fields. They are hammer and chisel technology, and break first normal form. There is nothing remotely relational about this application. There would be if the data dumped into repeat fields was structured into a related table as it should be. Bad technique, is bad technique. It doesn't matter how simple the database is. |
the options displayed every time, then you donn't need to have a
Relationship at all.
A Relationship is only needed if you want to narrow down the Value List
options for each Record based on the data in one of that Record's other
Fields.
Helpfull Harry
)
#16
| |||
| |||
|
|
In article<j8f8e2$fus$1 (AT) speranza (DOT) aioe.org>, cortical cb (AT) corticaldata (DOT) com.au> wrote: Do not use repeating fields. They are hammer and chisel technology, and break first normal form. There is nothing remotely relational about this application. There would be if the data dumped into repeat fields was structured into a related table as it should be. Bad technique, is bad technique. It doesn't matter how simple the database is. If you're using a second Table to hold Value List options AND you want all the options displayed every time, then you donn't need to have a Relationship at all. A Relationship is only needed if you want to narrow down the Value List options for each Record based on the data in one of that Record's other Fields. Helpfull Harry ) |
If it were 'appropriately' coded, the ID values of the 'value list'
items would be recorded, not the text equivalents.
Then one can use a PUM to display the related text value in the ID
field. But this facility doesn't exist in FM5 does it Harry?
#17
| |||
| |||
|
|
If it were 'appropriately' coded, the ID values of the 'value list' items would be recorded, not the text equivalents. Then one can use a PUM to display the related text value in the ID field. But this facility doesn't exist in FM5 does it Harry? |
In modern versions of FM, say, those shipping in this century, it is
indeed possible to include both key and text in value lists, show only
the text, and have the key entered when the text is selected.
You still have to use additional objects (like merge fields) to display
the selected text rather than the entered key, but proper relational
structure is possible.
--
Lynn Allen
--
www.semiotics.com
562.938.7890
Member Filemaker Business Alliance
FileMaker 10 Certified Developer
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.