Fuper

It only broke when I switched to Panther. Now it sees my target app as a document and won't let me select it. I can't believe there aren't more people screaming about this. There's got to be some way to get this fixed.

I got it to work, but it didn't seem to require attention to data types returned. Rather, the 1-to-10 exercise worked when I remembered to add the leading and trailing separators (the vertical bar: |). It became evident when I copied and pasted the demo formula into my own test file and began altering it piece by piece: If there is room for five parameters, it must always require separators for five parameters. Thanks for the encouragement. Now, Brother McKee, let's see what that "version" function is about...

Poor me is confoosed. When supplied with a gBeginDate and a gEndDate, my calc field using rgTx returns only -01, and the portal ain't coughin' up no stinkin' data fer crap like that. I've compared my syntax, field types, etc. with the demo file and find no difference; I even padded the range to match the demo and no luck. Is there better documentation available for this promising leetle gem?

I just did a little test on this and I believe that if you check the right portal, you will find that you've used fields from the relationship for the left portal. Right field(s), wrong relationship.

Calculation field equals: If (IsEmpty (Member_type, "", "yes") You are checking whether a single set of conditions exists, so use 'If'. (For multiple situations, use the 'Case' function.) IsEmpty returns true if the field contains no value, and the calc will return a null string; otherwise it returns "yes". Remember to choose "text" as the result type of the calc.

It sounds like you want the Emerg_Contact_Address to be the same as the Home_Address until a different emerg. address is entered. If I'm right, then here's an idea that instead of a relationship uses a calculation, an Emerg_Address_Entry field, and a layout trick. The entry field is a text field. The layout trick is that you make it opaque and place it under the Emerg_Contact_Address field. Make the latter transparent and disallow entry into the field. Here's the calc: Emerg_Contact_Address = If (not IsEmpty (Emerg_Address_Entry), Emerg_Address_Entry, Home_Address) If anything's been entered in the Emerg_Address_Entry field, then it uses that, otherwise it equals Home_Address. Voila, the whole process is invisible to the user, no buttons, no checkboxes. Thanks to LiveOak for help with this one.

Yes. That's the Answer, but I think you're looking for something more. For Understanding, make dummy files and play with dummy data (have fun). Have some data get looked up, change the 'prices', etc. and create a new record. View them As List, one above the other, and observe the behavior. You should see that the first record still has the old price (or cat's name, or bust size, or whatever fun dummy data you used). Features make more sense when you've played with them, testing different conditions.

Not experienced with this but I believe one way is to mark all the records in the initial found set in some way (such as using replace to place a '1' in a mark field). After any disruption of this set, it can be regained by searching for the marked records, OR by using a Go To Related Records. The latter might involve a global containing a '1', and relating that field to the mark field. Remember to clear the mark field when you're done with the initial set.

What Matthias has described is, that you create a relationship of the name field back to itself. A calc field can then be defined to equal the count of that field. Place this on a layout and see what happens when there is more than one record with a certain name--See? Your script can check for this condition. Alternately, another calc field can be defined to show an error message on the screen as soon as the count field shows that a duplicate exists -- no script required. You had a problem with validation failures interrupting your script, but this is what 'error capture' is for. Turn it on within a script, and no error from that point on will even cause an alert. At the point where the validation problem occurs, use an If statement to check whether Status (CurrentError) is from 500 to 509 (the codes for failed validations -- see FM Help). If no error, this function returns a zero. But don't underestimate the value of Matthias' solution.

wald - You've described a portal, including some of the options. Now you just need to make a couple more choices and go build the thing. It sounds like you only need a script if you want to keep this portal out of view and automate the actions needed to view it. To build the portal: Define a global field "g_Undone", text, and enter the value "not done". Define a relationship, g_Undone x order_status. (Define it in the file where the portal will display; this can be in the same file as the orders or another file.) Check the box for "Sort related records" and specify the order date field, ascending order. Finally, draw your portal and add the appropriate fields. There are options to how you do this. If the global field can be changed by the user, the contents of the portal can be made to change, thus displaying other subsets of records as desired. If you use a "1" instead of "not made", you'll conserve disk space. And so on. If you would rather not view the records in a portal, you could use the same relationship as above plus a "go to related records" step, in which case the sorting would have to be handled by a script.

It sounds like you want to have several color codes for each item. It also sounds, then, like the trouble you are having is that you want to use a separate field for each instance of a code, AND you don't want to have to create a relation between each code field and the color file. If it is appropriate, consider using a single code field and a single color field, and then either making them repeating fields OR showing them in a line-item portal. (The line-items would reside in a third file.) As far as a portal: You may say, "This is only one item, so why would I want to coomplicate things by putting its colors in line items in a separate file and showing them via portal?" But any item that can have two or more items attached to it is a candidate for such a relation: multiple addresses, multiple line-items. And multiple colors. They may not reside IN the item record itself, but they are viewable, printable, searchable, and displayable there. As for not having to enter the code manually:

Consider whether the report can be printed from a summary of a number of records instead of just one. If the structure of the report is at all repetitive (i.e. Preliminary matter; Section 1, item 1, item 2, ..., Summary; Section 2, item 1, item 2, ..., Summary,...) then the parts that are repetitive can come from separate records. A phone book would be an example, without the summaries. I've used FM to print a region-by-region membership directory of over 80 pages, with summaries providing the region and sub-region headings. You may say "No, the sections of my report are more like 'Animal, Vegetable, Politician,' and the visual structure of each is different, so they can't come from repetitions of any one single body layout." But don't forget that each record can have different fields filled in and left empty, and that Sliding can be used to get rid of empty spaces. Or that the body part can incorporate a large text field, with the records you then print from each containing a chunk of uniquely formatted text. You could output an ENCYCLOPEDIA in this fashion (with pictures, even). I should point out that this very neatly solves the problem of text breaking over page boundaries. Don't confuse getting a report to print out all at once with printing all the data from a single record ar even a single file. Relationships, global fields, and the fact that fields on a header, footer, or summary part can display data from the records immediately above or below, can all help you with this, too. See the question "Looking for a sample script..." under the ScriptMaker topic for a little more on this. Good luck. --Fuper

When you say that "of course, it will not print properly," is it because the number of items in the portal exceeds its size, and therefore some rows don't appear in the printout? Trying to copy the contents out of any number of records and then pasting it as some kind of lump into who-knows-what receptacle, is like reinventing the wheel. I have used two solutions to this: 1. Make a separate layout for printing that is l-o-o-ong enough to hold a portal that CAN hold the number of items you anticipate. This requires several things: Your printing script must not only switch to this layout but check that the number of related records hasn't exceeded the size of even your enlarged portal. The layout must be able to break over two or more pages without text in the portal getting sliced horizontally (this takes fine tuning and may not work with multiple printers); yet the layout must also be able to shrink (with careful use of the Sliding and Printing options) in case there are only a few items. Frankly, a pain. 2. The better option: Print from the multi-item file instead of the invoice file. The top of the printed invoice is a title header in the multi-items file. As long as you have a relationship BACK to the master invoice (such as for looking up the invoice date into each line item), you can use this relationship to display text from the master invoice on this title header, using layout text if not related fields. That's okay, because when it comes time to print you don't need to edit anyway. You may not like using a print script because you want to simply press Command - P and be on your way. Once you have it in place, however, the script is just as easy to use: It gathers related line-items into a found set using Show Related, then calls a script in the multi-item file that switches to the printing layout, restores page setup and prints, and there you are. Getting subtotals to display in the master invoice record is a similar process. And NO ONE WILL KNOW that it came from the multi-item file, not the actual master invoice. Sneaky, huh?

My solution to this has been to nestle a small, borderless rectangle with no filling into the top left corner of the layout. Then, when I want to copy elements from that layout to another, I include the hidden object in the selection. After pasting into the new layout I move the whole pasted selection up and left as far as it will go. When the invisible rectangle is stuck in the corner that's as for as things will go and they are in place. It can then be discarded -- or forgotten with little consequence.