Danny Joe

After converting to FM 7, many of my layouts which have sliding text boxes with merge fields end up neither printing nor displaying the sliding text boxes in preview mode. Browse mode looks fine. If sliding is turned off, the text boxes appear, but obviously don't slide. Sometimes the first text box or 2 will appear at the top of a page, and the rest dissappear until the next page, where the first one appears (as though the rest had been there invisibly) - and the rest are gone. The text boxes are set to print in the sliding - printing dialog box. Does anybody know what's going on?

thanks for the suggestions stanley! tour manager eh? how long were you able to keep that going? anyway, I would probably have taken your advice and re-done the whole database with scripts, but I just upgraded to FMP 7 developer, and it runs very smoothly now. Dan

Hi Stanley, thanks for the response. Currently I am now just trying from one machine... printing to PDF it's OS 10.3. There's a new probelm too now. Just upgraded to FMP 7 Develper, and a block of text with contains merge fields isn't even appearing in preview (though it is on the layout, and I see it browse mode. It doenst print either. If I leave sliding off, the text block appears, but pages too late. So.. 2 problems on the table now, can you help? Thanks, Dan

Hi Stanley, thanks for the reply. The name was changed in finder, not with the Developer Tool, for purposes of orginization. I wasn't the one working on the file at the time, so.. maybe this is when the slowdown became apparent. I've since added even more calculation fields, and the slowdown is worse. I added the bit about name changes becuase when it happened, FM had to ask the user to re-locate the related databases in finder. Maybe it searches some kind of history of where the file has been, and what it has been named with every calculation? If correctable, that would be a relief, but it seems unlikely. Shot in the dark. Regarding the necessity of viewing all 130 calc fields at once: Basically the calculations reveal the flow of royalties to producers licensors etc for an independent record label, (the calculations hash out terms of up to 11 contracts per record, which is why there are so many - and if you know anything about the music industry, you know these contracts are not straightforward) and it is important that with every transaction entry we are able to see that the money gets to the right people. I've put the "chart" on its own layout, for ease of browsing records (using the other layouts), but unfortunatelly the chart layout must be viewed at least one time per entry. (at least while the database is young and yet unproven). "Unstored calculation fields cause all kinds of delays" I wish I could store them! ...still seems like 15 seconds is too long, no? I feel like I'm missing something big, like driving with the parking brake. Dan

I've got a layout with about 130 calculation fields on it (mostly numeriical) which involve both related fields (from only 1 other database) and each other. I'm getting up to 15 second delays every time I do anything (change record, enter data into a field, run a simple script) from this layout. The computer has over 500MB of ram, it's a 2004 G4 iMac. This thing can handle 3D real-time graphics but not filemaker calculations? Seems like something must be wrong. A while ago, the related database had its name changed, could this have affected the performance? Anybody got any ideas? Thanks, Dan

Got a long (up to 5 pages) layout consisting of multiple sliding text fields, between which are container fields designed to space the text fields properly. Scripts and another database "spacers" give user control to spacing between text fields using jpgs varying in size from 6 to 16 pts, inserted with the scripts into specific spacing fields. This way the text fields dont end up cut in half (or 5/8, etc) across page breaks. This was already a pretty major work-around for FMP inability to properly break lines of text. Works perfectly in preview mode, but problem is preview doesnt match printed version. Obviously this ruins the fluidiity of the spacers solution, which depends on accurate preview. Who is the man with the plan?

Hey Lee, I got it working.. .and figured it out.. thanks a lot! Dan

oops . neither myself nor my Mac seems to know what to do with a .php file, and filemaker turns it into a funny looking table, certainly not what you intended.. should I have done something other than click on Attachment?

yes, that also gives me the problem of having the entire line indented, not just the second part.

A: it doesn't regard calculations. B: It offers me new hope of being properly answered

I'm trying to indent the second half of a line without also indenting the first, so that the end result - doesn't (can't do it here either) ---- look like: Category: datadatadatadatadatadatadatadatadatadatadata datadatadatadatadatadatadatadatadatadatadata datadatadatadatadatadatadatadatadatadatadata So I'd like all the data evenly indented to the right, leaving space below "category." The problem is, every time I indent part of a line (data) the whole line (including the category) is indented. Any ideas?

Hi Lee, thanks for the reply, but it looks like I'll need a work-around. When I use the paragraph (text) formatting in layout mode to indent my merge field, it has the correct effect, except that it also affects the preceding merge fields on the same line as the one I am trying to indent, which I don't want. Do you know what I can do about this? I have a vague memory of seeing some kind of calculation function which sets the indentation within calculation text. Maybe that was a plug-in. Thanks, Dan

Hi Ralph, thanks for the reply. I guess I wasn't clear enough in my question though. I'm more concerned not with the initial indentation, but rathar that the text stays indented for the next lines. The field is a merge field which begins indented, but when the text wraps across the page to the next line, it doesn't stay indented, instead, it goes back to begin again at the left margin. I can't pull the tabs over on my layout becuase this merge field does not always appear, and I don't want the other text/merge fields to be indented. I thought I'd seen some kind of character or function to insert into the calculation itself, keeping the text indented. Any ideas? Thanks, Dan

Hi - I'm sure I remember from somewhere that this can be done - how do you indent text within a calculation field? Is there a function, or special operator?

Hi Dan - I thought of this just after posting my last reply, and tested it as best I could considering that the sliding text fields vary in length and number of lines from record to record. So I adjusted the height of the problem field in semi-line increments, but this did not solve the problem. I have developed a complicated work-around which involves another database which adds space between specific fields using scripts. ... And I'm leaving the office for a month tomorrow... nevertheless, if you have another idea, please post it! It would be great to have the simple solution waiting for me when I get back. Thanks, Dan

Hi Dan - Thanks for the reply - I guess my message left room for ambiguity. Actually it's the bottom edge of the sliding field itself which doesn't slide up to the bottom of the text within that field - I am aware that if there is a hard return at the end of the text, there will be an extra line defined in the field, but in that case the bottom of the sliding field leaves an entire extra line of space (and with evenly spaced lines of text, my layout is ok to print, no text cutting at page breaks) However, in this case, the bottom edge is sliding up to about half a line of text's worth of space below the text itself. this disrupts the continuity of the layout (each line of text being 4 mm, extra space being around 1.5-2 mm) and causes the text to clip at page breaks. I have a lot of sliding text fields in this layout, and it spans several pages. I can't figure out what is causing this mysterious extra space to restrict the sliding... Thanks for your help, Dan

Hi I hope I'm in the right forum. Does anyone know what might cause sliding fields to stop short of the bottom of the text in the field - by about half a line of text(in preview mode)? it's a mystery to me why it is happening, and causing printing problems at page breaks. thanks!

Hi there, I sure hope somebody can give me a hand on this, I've spent a couple of days trying to solve it. I have a layout with mutiple text fields (hairline borders) all stacked up one after the next. These fields contain different sections of contracts, among the files in the database they are sometimes present, sometimes not, and of varying lengths. They are set to slide up, and contracts vary in length from 2-5 pages. The problem is, at page breaks, text gets cut so that it is partly on one page, partly on the next. I have tried adjusting the starting point of the first field, along with the size of the body to get the page to break between lines of text, but as soon as the first pages are ok, later pages get cut, or pages from a contract in another file gets cut. There doesn't seem to be a solution which works across all records. I had the idea that perhaps the borders of the field were adding extra space of various lengths to each page, so I added "spacer" fields between each text field in order to compensate - after toying with the height of the spacer fields, stil no luck - and I noticed that some fields seem to add an unpredictable amount of extra space beneath the last line of text... Please make me feel like a fool for having missed the obvious!! Thanks to whomever has time for this. Dan