Leader

I tried using GetNthRecord() shortly after FM-8 came out and I tried again this week, but in both cases (seeking a record field in a different table) I do not get reliable results. This time I actually hard-coded integers for the record numbers 1, 2, … etc. What I got was record 2 twice and then ? values. I just don't see how I could be screwing it up this badly. Has anyone else had problems like this? Also, I'm really curious why the record must come from a related table and if this could have something to do with my problem. It seems it SHOULD have sufficient information with the table::fieldname and record number, doesn't it? Ah well.

Fenton, I downloaded the pieces you suggested and wanted to let you know I appreciated the links.

Fenton, I downloaded the pieces you suggested and wanted to let you know I appreciated the links.

Ah! Good question. It was a calc field with a relational reference. It doesn't show unstored, but apparently the older FM3/4 allowed the relatiional reference to work and FM8 doesn't. Thanks.

Your question about an invisible character was raised by someone locally here. I'm just not 'seeing' anything invisible (chuckling), but I haven't yet brought it up in a hex editor. Thanks, Fenton. I'm so used to 'wrangling' XML by hand, I might not know what to do with my spare time! I will post a sample along with the DTD if one of the programs you mentioned doesn't detect anything.

Hmm… No scripts are involved, so no to both questions. When I leave that layout or even the file and return to it, the 'bad' result is still there, the value that never seems to update.

I imported a FM3/4 DB into FM 8.2 and I've hit a snag. The file has a Summary field with the Min function, and it returns the lowest integer just the very first time, but does not update even as records with lower values are entered. This holds true whether the Summary field is in the footer or the body. I have to believe this worked in FM3/4, but I'm baffled why the field isn't updating in FM8. I've also tried Max and Average functions with similar results. I'm out of bright ideas what I might be doing wrong. Help!

Actually repeating fields were often misunderstood and misused in the early days of FM's minimalism. They are in fact VERY useful if you use them properly; i.e., like 1 dimensional arrays in which you have a clear or even fixed upper bound.

It's pretty easy if you already have the script working for one field. Just use subscript notation, such as field[$i] (FM8) or field (FM7). Use your loop construct to bump the value of i or $i.

I'm had two ego blows in one day. I've used XML for a few years and planned to do a demostration of importing XML into FM8.2. Instead, FM8 refused to import the XML, reporting an error on the 3rd to the last line of the file. I've stripped the file down to perhaps 10 or 12 lines (from 600+) and FM8 continues to report an error on the 3rd to last line. I just don't see it. The XML example seems well-formed, appears to match the DTD, has closing tags throughout, but FM8 rejects it without giving a specific reason. Has anyone experienced this? Any ideas? Thanks.

Wow, good questions. I'm working without a reference handy, but I'll take you as far as I can. AutoEnter calc wasn't new with 7, it went back to at least FM3, if not earlier. The Evaluate() function is much newer and frankly I had problems with it in 7.0.0. You are on the right track: If you use AutoEnter without Evaluate(), you'll get a snapshot at the time the record is created. If related information is later deleted, the field will remain unchanged, assuming the relationship isn't flagged to delete in a reflective relationship. If you use Evaluate(), be sure the actually trigger is rigidly controlled so it won't update at an inappropriate time. In this regard, think of Evaluate() as the Relookup menu command

Wow, good questions. I'm working without a reference handy, but I'll take you as far as I can. AutoEnter calc wasn't new with 7, it went back to at least FM3, if not earlier. The Evaluate() function is much newer and frankly I had problems with it in 7.0.0. You are on the right track: If you use AutoEnter without Evaluate(), you'll get a snapshot at the time the record is created. If related information is later deleted, the field will remain unchanged, assuming the relationship isn't flagged to delete in a reflective relationship. If you use Evaluate(), be sure the actually trigger is rigidly controlled so it won't update at an inappropriate time. In this regard, think of Evaluate() as the Relookup menu command

Wow, good questions. I'm working without a reference handy, but I'll take you as far as I can. AutoEnter calc wasn't new with 7, it went back to at least FM3, if not earlier. The Evaluate() function is much newer and frankly I had problems with it in 7.0.0. You are on the right track: If you use AutoEnter without Evaluate(), you'll get a snapshot at the time the record is created. If related information is later deleted, the field will remain unchanged, assuming the relationship isn't flagged to delete in a reflective relationship. If you use Evaluate(), be sure the actually trigger is rigidly controlled so it won't update at an inappropriate time. In this regard, think of Evaluate() as the Relookup menu command

I suspect you are placing at least 2 unwarranted burdens upon yourself: (1) Trying to limit yourself to using just one field for everything, and (2) Allowing clerks to enter whatever the hell they want. (I hear this strident voice in the background saying, "This is the way we've done it for 30 years, and this is the way we want to keep doing it.) What is 'too many' in the scheme of things? Dozens? Hundreds? Or, to word this differently, is it possible to identify every possible size? If so, why torture the developer (yourself) with trying to guess what the data entry clerk meant? Put another way, imagine a ballot or survey or even a large columnar menu of options. It is reasonble for them to run down a column clicking on the items they want? No rule says you can't use more than one field to assemble your information, even one or more fields per column; see what I mean? Say you create 3 columns with a total of 5 categories (only if you need categories) which will result in at least 3 fields (1 per column) OR 5 fields (1 per category). Do NOT give the user the field option of OTHER or EDIT. If you want to process everything en mass, create a calc text field that concatenates the other 3 (or 5) fields together. (In a worst case scenario, if you had thousands instead of dozens of items, you might even have multiple pages.) Since you have total control over these fields, you also have control whether commas or blanks separate the entries, and you can use PatternCount() to count the number of, say blanks or commas, and therefore deduce the number of entries selected. HOWEVER

I suspect you are placing at least 2 unwarranted burdens upon yourself: (1) Trying to limit yourself to using just one field for everything, and (2) Allowing clerks to enter whatever the hell they want. (I hear this strident voice in the background saying, "This is the way we've done it for 30 years, and this is the way we want to keep doing it.) What is 'too many' in the scheme of things? Dozens? Hundreds? Or, to word this differently, is it possible to identify every possible size? If so, why torture the developer (yourself) with trying to guess what the data entry clerk meant? Put another way, imagine a ballot or survey or even a large columnar menu of options. It is reasonble for them to run down a column clicking on the items they want? No rule says you can't use more than one field to assemble your information, even one or more fields per column; see what I mean? Say you create 3 columns with a total of 5 categories (only if you need categories) which will result in at least 3 fields (1 per column) OR 5 fields (1 per category). Do NOT give the user the field option of OTHER or EDIT. If you want to process everything en mass, create a calc text field that concatenates the other 3 (or 5) fields together. (In a worst case scenario, if you had thousands instead of dozens of items, you might even have multiple pages.) Since you have total control over these fields, you also have control whether commas or blanks separate the entries, and you can use PatternCount() to count the number of, say blanks or commas, and therefore deduce the number of entries selected. HOWEVER

I suspect you are placing at least 2 unwarranted burdens upon yourself: (1) Trying to limit yourself to using just one field for everything, and (2) Allowing clerks to enter whatever the hell they want. (I hear this strident voice in the background saying, "This is the way we've done it for 30 years, and this is the way we want to keep doing it.) What is 'too many' in the scheme of things? Dozens? Hundreds? Or, to word this differently, is it possible to identify every possible size? If so, why torture the developer (yourself) with trying to guess what the data entry clerk meant? Put another way, imagine a ballot or survey or even a large columnar menu of options. It is reasonble for them to run down a column clicking on the items they want? No rule says you can't use more than one field to assemble your information, even one or more fields per column; see what I mean? Say you create 3 columns with a total of 5 categories (only if you need categories) which will result in at least 3 fields (1 per column) OR 5 fields (1 per category). Do NOT give the user the field option of OTHER or EDIT. If you want to process everything en mass, create a calc text field that concatenates the other 3 (or 5) fields together. (In a worst case scenario, if you had thousands instead of dozens of items, you might even have multiple pages.) Since you have total control over these fields, you also have control whether commas or blanks separate the entries, and you can use PatternCount() to count the number of, say blanks or commas, and therefore deduce the number of entries selected. HOWEVER

To rephrase, all you want is to essentially replace the double quotes with a comma, blank, or tab? Use the Substitute() function. Bang. You're done. If you need to process these 'codes' further, then pop them out into repeating fields... but you do have to learn how to properly use repeats. If you're just starting with FM, you might want to wait a few weeks to get more of the basics solidly under your belt.

To rephrase, all you want is to essentially replace the double quotes with a comma, blank, or tab? Use the Substitute() function. Bang. You're done. If you need to process these 'codes' further, then pop them out into repeating fields... but you do have to learn how to properly use repeats. If you're just starting with FM, you might want to wait a few weeks to get more of the basics solidly under your belt.

To rephrase, all you want is to essentially replace the double quotes with a comma, blank, or tab? Use the Substitute() function. Bang. You're done. If you need to process these 'codes' further, then pop them out into repeating fields... but you do have to learn how to properly use repeats. If you're just starting with FM, you might want to wait a few weeks to get more of the basics solidly under your belt.

Are you still talking within FM? I had a dictionary that had a number of separate fields including etymology, definition, cognates, pronunciation, and other items, non of predictible size. I was satisfied by this particular solution. That's not to say others may not serve as well.

Are you still talking within FM? I had a dictionary that had a number of separate fields including etymology, definition, cognates, pronunciation, and other items, non of predictible size. I was satisfied by this particular solution. That's not to say others may not serve as well.

Are you still talking within FM? I had a dictionary that had a number of separate fields including etymology, definition, cognates, pronunciation, and other items, non of predictible size. I was satisfied by this particular solution. That's not to say others may not serve as well.

Regarding font sizes: If a PS font package contains 10 point and 12 point but the display calls for 11 point, the system has to build a font on the fly and conceivably anti-alias it.

Regarding font sizes: If a PS font package contains 10 point and 12 point but the display calls for 11 point, the system has to build a font on the fly and conceivably anti-alias it.

Regarding font sizes: If a PS font package contains 10 point and 12 point but the display calls for 11 point, the system has to build a font on the fly and conceivably anti-alias it.