It's a little more work, but you could do this in a related table instead of a single field in the current table. Each record in the related table corresponds to a chapter. Generate the records based on the same method you're using to generate the value list. Use a matrix of single-row portals, starting with the appropriate row in each to point to the desired record. Then you can order them however you want.
Of course, unless you actually need the data to be in a related table (although it's arguably a better setup), the view might not be worth the climb.
There is no choice for that, but I question why and how you are doing this. It look more like something you would want in a drop down from a value list, which among other things would take a whole lot less real estate. What is the circumstance that you are needing this and maybe be open to other ideas on how to do it.
My Client is tracking Chapters being translated for a given set of books . I am already generating the required chapter check boxes dynamically ( for each book ) using a conditional value list . It is working well as expected .
Screen real estate is not an issue the layout is almost empty .
I just thought it will be easier to read from L > R than than from TOP > BOTTOM
Select your field right bottom and drag towards up right, it will resize; when getting quite narrow (in height) and quite long ( in length) you will eventually reach what you seem to look for.
It will look awful, though.
Investigate using an array.
and SCROLLABLE horizontal portals and/or grids (ala spreadsheet) for portals would be so wonderful.
make a feature request (all of us)!
I've used brute force to place single instances of a value (from the list) in different positions.
_ 1 _ 2 _ 3
_ 4 _ 5 ...
But it's not flexible.
There are workarounds that may involve repeating field (with the values, one per repeat) and scripts to push the value (of the repeat) into the real field (or remove upon second click).
Remember that "value-lists" fields (such as the checkbox format) is really just a field with many values separated by returns. The ORDER of selection is not important. To test: put the same field on the layout, with one just plain and one formatted with checkbox (from the value list). When you check the boxes, notice the changes in the "plain field".
Some possibilities, perhaps?
As correctly outlined by erolst in another parallel thread, this is a case in which the correct data model does not have a logical, intuitive, desired, natural etc way of being represented.
If Horizontal portals are hard, at least allow for -90° rotation of existing, vertical ones.
WriteLn('Time flows from left to right, not from top to bottom or bottom to top')
WriteLn('A lot of data in our databases is time-based')
Exit loop if (you_got_it)
Your pseudo code cracks me up ...
Try using a value list with the numbers entered in staggered order. Eg, "1¶4¶7¶2¶5¶8¶3¶6¶9". Then size the field so that it's 3 numbers wide.
Caught myself thinking about how we could stagger the numbers with a custom function.
I must be in need of a weekend.
This makes result like as
I'm doubtful this is better than default... user would think "why 2nd line don't have 4 values?"
If you change height to 4 lines, it shows 8 values horiontal, you can't force 10.
The custom function would need to take as a parameter a desired number of rows or a desired number of columns.
This is clunky, but it might work;
Create several fields, each with 4 values in them, eg Chapters 1-4. 5-8, 9-12 etc. Create another calculation field which gathers all the data together for your use.
On your layout, make the fields wide enough to show all 4 values, and only tall enough to show one value each.
Will this do the job?
sharon, No calculation field needed!
You can place the SAME field on the layout and assign different VALUELISTs to it:
myfield first instance has 1-4
myfield second instance has 5-8
The values will still "gather" as return-delimited in to the field. Only the DISPLAY of the checks will be in the appropriate place.
I have even had ONE valuelist per value and placed the same field in unique ways, such as the columns. This was a good way for IWP, for example and gave the effect as you would in HTML/web where each input type checkbox or radio is a separate line of code. Another time the appearance was a circle (such as a clock) in the placement of each value, although this was radio buttons, not checkboxes. But the method was the same with separate valuelist(s), same field.
Yes, this method is not very flexible (you have to precisely place the copies of the field), as you cannot just resize one field with all the values. And you must create all those distinct value lists to use.
Binu, there have been some clever ideas proposed above, and I'll bet that at least one of them will give you what you need. I just want to throw in a little extra info about how checkboxes work, so that they don't sneak up and take you by surprise.
(1) Data Storage. You can set up a field as a checkbox so that the values will be displayed in the order you prefer, but that doesn't mean they'll be stored that way. They're stored, separated by returns (⁋), in the order in which you checked the boxes. Here, for example, is the exact same field, side by side with itself, the blue formatted as checkboxes and the purple formatted as an ordinary edit box. As you can see, the values appear in a different sequence because of when you did the checking. This may or may not make any difference to you, but you should be aware of it just in case.
(2) Numeric Only. If you define a checkbox field with the validation "Numeric only", you can't check off more than one box.
(3) Legacy Data. If you've got a checkbox field that contains possible values Ann, Bob, Che, Dee, Eva, and Fay, and you've already checked off values for them in a lot of records, be advised that those values will still be there even if you subsequently change the display of the field by editing its value list. For example, if you decide you'd rather show Robert instead of Bob, that doesn't automatically mean that all the existing values of Bob will magically be converted to Robert. They'll still be there as Bob, just not visible (which might be even worse than losing them altogether). And if you take the word Eva out of the value list, that doesn't take the value Eva out of any fields where you've already inserted it.
Thank you ... That gives me a better understanding of how checkboxes work .
Anyways this thread has given me a lot of useful insight ...
you can place the same field multiple times and create "smaller" value lists for each field :
same field 4 times on layout, but using different valuelist everytime
Better is to actually solve the problem, with an appropriate data structure. Most of your posts and your problems would be eliminated if you followed early replies and built it right.
Thanks Bruce , I HAVE followed the instructions and changed the data model now. So a lot of the questions are now not valid .
Can you provide, for instance, a screen shot of your relationship graph?
This is new Data Model each Chapter its own record . I don't need to store multiple chapter values in a field anymore. Thank you all for the inputs .
By the way, I personally think the checkbox fields FM has are ugly and look like they came out of the 1990's.... oh yeah... they did. So what I almost always do is use two graphics, one of a checkbox and one that is a blank box to behave as checkboxes. I put the checkbox on top and set it to hide when the field is boolean yes. On top of both boxes I make an invisible button that toggles the boolean value of the field. It is certainly more of a pain to use than the included checkboxes, but it sure looks better and you can space things out how you want them to be.
A selectable portal or list view in a card window sounds better.
Is being asked for since years (vote here):
It's possible to set up what looks and acts like check boxes, but is really a selection portal where you are clicking buttons that change appearance to show which values are selected. This method can generate the same return separated list produced by a standard check box format or it can build a set of related records (and clearing a check box deletes a related record). That table of related records can make many reporting tasks much simpler than trying to tabulate data out of a set of records with return separated values in one field.
I haven't done it, but a variable array could also be updated with such a UI feature.
This provides scroll bars as an option and the horizontal portal techniques also can work with this.
Might be interesting also to see what might be achieved with a single selection portal where each row shows a button bar with calculated labels and script parameters to match...
If anyone reading this is interested and hasn't already seen it. working examples of portals that simulate check boxes, two different working examples along with detailed documentation may be found here:
Adventures in FileMaking #2-enhanced value selection
Retrieving data ...