joecollver

i tried that too, without success. what i ended up doing is changing the lookups to normal number fields, then have the recalc script manually set each field to the value in its corresponding unstored calc. It's an ugly solution, but it'll have to do for now. thanks again for the help

one thing that it might help for you to know is that all of my fields are in a lineitems database that i'm editing through a portal in another database. my recalc script is not in the lineitems database.

I just tried putting data in the look-up fields manually, then running the recalc script to see if they would change. They didn't. Is my recalc script the problem then?

i tried this approach but it doesn't seem to be working. i set up the self-relationship like you said, and tried making 5 lookups to test with. they look up the value through the self-relationship, but no matter what I try all of these lookup fields start as empty and remain empty even when I run the recalculate script (set field(_trigger, _trigger)) I thought I did everything like you said.. am I missing something?

sounds like a great way to do it, but how exactly do you make the lookups "triggered on a field" ? Thanks for your help!

The problem is still there even after I eliminate some of the unstored calculation fields from the layout. Is there anyway I can make these fields number fields with a calculated value, then create a script that recalculates all the values? sort of like a refresh button for all the calculations?

I've noticed after adding around ten to fifteen unstored calculation fields to my lineitems database that fmpro was running significantly slower than before. I would consider changing the calculation fields to number fields with a calculated value, but then they wouldn't update continously, which is what I need them to do. None of the calculation fields have anything more complicated than a case statement inside them, so why is this computer (pentium 4) getting so bogged down by them?

That probably means if I have any fields containing Chinese text that I want to search through, I'll have to change this parameter to ASCII for them as well, right? --I just tested it and fmpro finds the chinese text no problem.

The question I have relates to this. Currently I'm running a script like this for printing: Go to Layout ["printlayout"] Enter Preview Mode [pause] Print [] I'd like to turn Allow User Abort off, so pushing cancel while paused in preview mode won't leave the user stuck on the print layout, but then there's no way for the user to cancel if they don't want to print afterall. I could add: Show message[Print this layout?] OK/Cancel after the print preview, but then the user has to press continue to stop pausing, then press Ok to print. Which doesn't seem the right way to do it either. Anyone know the better way to do this?

This has to be the most backward, counter-intuitive way to make the transparent part of gif images actually transparent, but if it works I guess it'll work. I was just about to write a post asking why my transparent images weren't working right when I ran across this thread. So... does anyone know why FMpro made it this way?

I've run into an interesting problem with the search routine I'm building into a solution. Say I have a record whose email field has the value "a@a.com" If I perform a search for "a@a.com" no records are found. But if I only search for "a.com" it finds the record. I know the problem is with the "@" but I'm not sure how to get around this, since users will want to be able to search for email addresses using the complete address.

I have two fields in a database, one is short and to the point, the other is detailed. Let's call them PrereqSummary and PrereqDetail. When a new record is created, User A fills in the PrereqSummary. Later, User B, a prereq specialist, will fill in PrereqsDetail. I'd like to have PrereqDetail look up the text in PrereqSummary and start with that as its initial value, so that UserB doesn't have to retype everything UserA entered. The problem I'm having is that look up fields are calculated when a new record is created, so no matter what is typed in PrereqSummary you won't see it in PrereqDetail. Is there a way to change when the actual looking up of the value is performed? Or maybe there is a better way to do this.

Why is the Paragraph formatting button dimmed whenever you bring up the text formatting window for a number or date field? It makes it impossible to change the indentation for a date or number field without specifying a different field, making the changes you want (e.g. adding 4 pixels of indentation), then switching back to the date or number field you originally specified.

I tried all different combinations of values for the line spacing settings, yet the field still goes buggy once you enter in more than one line of text.

I just installed the 5.5v2 patch, and the bug is still there. CobaltSky must be right, because when I tried changing the field's font value from the Chinese font I'm using back to Arial, the problem goes away.

I think I did a foul job of explaining what the problem was, so I captured an image of what it looks like when I'm entering in the data: As you can see in this pic, once the data I'm entering is longer than the field, it adds a return above the text for each character I type. Once I move on to the next field, it stops looking like this, but still, it looks messy especially if you are entering several characters beyond the length of the field.

I don't know if this is just my system, but when I enter text into a field in browse mode and the text is larger than the field, the field gets larger with each character I type beyong the space of the field, looking as if it was adding a return above and below what I'm typing.... when I switch to the next field it stops looking quite so sloppy, but still it doesn't look like it's displaying the data correctly. I'm thinking this may just be because I'm using a non-English operating system, but has anyone else encountered anything like this?

Yeah I was having the same problem... random rows printing on top of other rows... I'd bring the ones that weren't printing to the front which would only make other rows disappear. but now that it's out of the portal and in the lineitems file the layout works fine.

it seems every new record I create after I set up this calculation field will enter in the i.d. number correctly, so the merge fields end up working. But I have to go in and manually enter the i.d. numbers for all the previously existing records. Why do calculation fields work like that? It seems like it should automatically update all the data in the field once you change the parameters of a calculation field.

There's a section on this in the fmp5.5 user's guide, but I think their example's a little off so I'm going to have to ask for help here. I'm modifying the fmpro solution framework, and trying to make my own print layout in the lineitems file. Everything is working great now, except for two of my merge fields. The merge fields, which look something like this <<People_Cust Number::CompanyName>> worked just fine in the Invoice file because it had a relationship with the People file with the customer ID number as the match field. But the line items file has no such relationship. The user's guide says to create a new field in lineitems, a calculation field whose value is equal to Invoice_Inv Num::CustomerID, as a way to pull out the ID number from the invoice file, so I can define a relationship between the people file and the line items file using the customer i.d. as the match field, thereby getting my merge fields to work. It sounds simple, but when I tried it I got nothing in the cust. i.d. field in the line items file. Am I doing something wrong, or, is there a better way to solve this problem? Thanks

yeah after a little more reading and tweaking I found the answers to both the questions. Thanks for the help. the second problem was solved when I did a search on the line items file for the record I needed and out it popped. It's embarrassing to find out 15 minutes after you post a question that the answer is so readily obvious.

So here's what I think I need to do: 1) Create a new layout in Line Items file, with title header, body, and footer 2) Create a reverse relationship back to the Invoice file, and put all of these fields (shipping date, carrier, port of arrival, etc.) in the title header. 3) Copy the rounded rectangle-table contraption from the old layout, minus the portal, and put it in the body of the new layout. 4) use Vaughan's fancy script to direct get from the Invoices file to the Line items file, find and sort the records I need, and display them. Sounds great, but, being new to this, I still have a couple of questions. 1. In this layout, what makes the body of the layout automatically repeat itself for all of the records in the found set? 2. How come after entering multiple test records in the Invoice file of the solution framework, I can't for the life of me find a single entry in the Line items file? The relationship is there, the data can't be in the Invoices file itself, so where is it hiding from me? Again, thanks for the help.

I'm able to incorporate Chinese text into the solution I'm working on with fmp5.5, and the solution framework has had no problem storing Chinese in fields or lookup tables. I don't think the sort routines will work correctly, but I haven't needed that yet so no worries. What really REALLY bothers me though is using Fmpro in a Chinese version of w2k. I get all kinds of lovely surprises like unreadably small numbers in the object size tool, to text getting cut off in all the options and preferences screens I bring up. Anyone else using FMpro in a non-English operating system who knows how I might get rid of these little annoyances?

I've been having some freezing problems when I work with the FM solution framework, but I thought it was because I was using a double-byte language in an English copy of Fm pro.

Something I haven't seen people bring up in these portal/printing/invoice threads is the issue of invoices where the information for each item is more than one line. The invoice I'm working with has at least two dozen fields for each item, all formatted to look like a table inside a rounded rectangle. After finding out the hard way that portals are the WRONG way to print this layout, I'm a little worried that the method Vaughan and BobWeaver give won't work for invoices that need more than one row for each item. There's a good possibility I'm being an idiot and there's nothing to worry about, but if this is the case, could anyone tell me a good way to avoid having these large rectangles split in two when they reach the end of the page? You help is appreciated