amigotto

Unfortunately, it looks like I have to abandon the switch from using jpeg images to pdfs. The reason is not so much the question of printing multiple page pdfs, since I have abandoned that and have been saving each page as a separate pdf file. The main reason I'm switching back to using jpegs is that pdfs DO NOT PRINT at 300dpi no matter what I do! They only print at low resolution. I have scoured both this site and everywhere else with not even a mention of this problem. Is it possible that I'm the only one who wants to print pdfs embedded in a layout in a container field? Is that just a crazy idea? Am I nuts? This works fine with 300dpi jpegs. OK so where did I put that pdf to jpeg converter app...?

Thanks for your reply. Yes, display pdfs in container fields on a layout and print them, as I have been doing for years with jpegs (which are all 1-page images). Yes I wish to have FM add a header and footer to the multipage PDF. I understand it can't be done, so I'll just split multiple page pdfs into 1 page documents and all will be fine. The reason I was using jpegs is that our environment included Windows, which can't display PDFs natively in FM. But now that the office is all Mac OS there is no need as most of the images are PDFs generated from text, which are much more manageable in terms of file space and overall system load. Also I no longer have to convert PDFs to JPGs, etc. It would be a great feature though...

Anyone?

Im trying out FM12 and have a container field used to hold links (via calculation) to image documents. Up to now, the images were saved in jpeg format (1 image per page) for mac/windows access. I am moving to a Mac only environment and prefer to use PDFs, since most of the documents are originally in PDF format - mostly text, so I won't have to convert them to jpegs as I have been doing. Everything works fine except for printing multiple page PDFs. Is it possible to print multiple page pdfs from a container field optimized for interactive content? The layout adds header and footer data to each page, so printing must occur in Filemaker. Other than saving each page of a multiple page document as a separate PDF, is there any solution available? Thanks, Alvise

That's it - thank you!

How would I report a successful script run? By setting a "successful run" date field with today's date as the last script step?

Hello, I've searched for an answer to my problem here and on Google but have not found one yet. Can anyone help? I have an Open Script that generates a report, saves as pdf and sends it as an email attachment if criteria are met. How do I check if either the file has been opened today or if the script has run today so as to avoid generating the same report and email numerous times on the same day? Cheers, Alvise

OK - I'll try this The fact that it is error prone is what's most important for me - in practice the only fields that describe the overall payment are the date and paymentnumber. But even these are verified at the time of payment or reconciliation, which reduces error to a minimum in this case. So if I create a separate table, that table should include all fields in common between payment items that would need the sam payment number, correct? Bank statements are numbered manually (by hand) on the printed bank statements. These numbers are then entered manually in the database. This is the weakest link in terms of being error prone.

Woops! Spoke too soon. Although a step closer, reimbursements can have 1 payment item as well, so I still need to omit these. :idot:

Got it! Omit the records whose "reimbursement number" field is empty! Thanks guys! Can you explain why having the payment items in a different table is a better model? I should maybe look into this for a future upgrade to the system.

Payments are numbered sequentially according to bank statements upon reconciliation (manually). Multiple payment items are usually (but not always) a result of reimbursement and are grouped by a "reimbursement number" field. For example - a credit card bill will have several individual payment items. Each day when payments are made a report is generated. The credit card items are grouped so that the report shows the total amount for the bill, which is what appears on the bank statement. The final financial reporting for the project includes the individual items (with the same payment number) sequentially listed according to the bank statements, and another report which has a subsummary part by payment number which shows all payment totals according to the statements. Another report shows only grouped payments - which is the one I now manually omit unique numbered payments from. Yes, since there are many accounts it is possible to have the same payment number on the same date in different accounts (event the same chque number!), which is why the find duplicates doesn't work.

Since I have many reports set up which use the database the way it is setup now, it would mean reworking the whole database which is not possible at this time. I can't see how I could generate the reports I do now if I had to use separate tables to do so. (I'm not that proficient yet). The way it is set up each payment item in the table is entered as a separate record (which has specific related documentation, accounts, budget items, tax deductions, witholding caclulations,etc). Tom the find duplicates syntax doesn't work in this case because I'm searching for duplicate entries in one field but at the same time I have to search a specific account (another field). At the moment I just generate the report and omit the unique records manually. I only takes a minute or so (for a 500 record project) but it would be nice if I could automate it. Thanks for your help.

Hi Guys, I have an "expenses" table which includes project, account number, payment date and payment number fields. In the case where one payment may represent two or more expense items, I can have two or more records with the same payment number, such that when those records are added together, the total payment amount for the same payment number matches the amount debited from the account in the bank statements. For example, if a hotel bill containing room charges and restaurant charges is paid with one cheque or credit card transaction, two records are entered with the same payment number, one for the room and another for the restaurant. Or when reimbursing employee expenses, etc. I'm required to produce a report which includes only those payments which represent grouped expenses. In other words, I need to find all payments with the same account name, payment date, and payment number, omitting records which have unique payment numbers. I have a layout which shows the data as required but how can I automate the omitting of unique records?

Thanks to all for your input! I have modified the script so that the record in the credits table is created based on a relationship. All I needed to do was create a field called "Account Credited" in the debits table which is only available on a layout called by a script button to "export record to credits". Once the account is selected by value list and passes validation to avoid selecting an ineligible account, a new entry is created in the credits table and all necessary fields are set via the relationship. As I was wrapping my brain around this problem I realized that both of the remaining 2 fields that required entry in the credits table could only have one "correct" possible choice from their associated value lists based on the data in specific fields in the debits record (one of these require data that is not necessarily the same as the data in the corresponding field in the debits table and the other field does not exist in the debits table and therefore requires entry). So these 2 fields are now set by calculations, which means no user error. HOWEVER, I still need to use the Pause/Resume script step when the script is called and waits for the user to enter the Account Credited field. I have a continue button there so the user can make sure she has selected the proper account. I was trying to avoid this in order to streamline the process earlier but in this case the layout contains only the Account Credited field as a Pop-up menu and the continue button. It is a much more streamlined solution requiring only a verification of the newly created record in the credits table and most likely no modification. So I guess I can live with it. (OK - so I have a cake. I love this cake. I love eating this cake. But I love this cake. It's really good cake...Hey! were's my cake!...)

Splitting the script into 2: I tried Splitting the script into 2 as you describe and that works, but there can be instances where the 2nd part does not trigger or conclude and the final instructions wouldn't be passed to the user. The way I have it now works very well. I see no problems with it. WHY shouldn't I do it this way? Why 2 records for 1 transaction? As for two records for one transaction, it is really two transactions. All records correspond to transactions in bank statements. So I have a record which corresponds to an outgoing sum in one account statement, and one record which corresponds to an incoming sum in another account statement. I guess I could create the incoming record via relationship but I only need to identify which account to credit when I'm transfering funds from one of our accounts to another of our accounts, and not for all payments. In any case I thank you for this suggestion. I will look into doing it this way. I could set the values of 2 of the 3 fields to be modified automatically based on fields in the outgoing record, eliminating the need for both the script as well as manually entering data in the 2 remaining fields. In this case I would add a credit account field in the outgoing table (which is one of the 3 fields to be filled in in the incoming table), which would be the match field for the relationship, correct?

I'm sorry I thought I explained WHY. What further information do you need? Is there a way of doing this without using Pause/Resume?

The fields are drop down menus (value lists) whose content is validated to reduce the chances of error and cannot be incomplete or empty as this will result in a failed validation, so there can't really be any incomplete information there in this particular case. Clicking outside the field will bring up the save message, which will fail if you click save. But I agree it could be dangerous in other circumstances.

Thanks Vaughn. I have made the change you suggested. The script is used in an accounting module when transfering funds from one of our bank accounts to another of our accounts. I use multiple bank accounts for different projects either to conform to specific Brazilian legislation which governs the tax deductible sponsorship of cultural events (which is the area my firm specializes in) or for certain accounts that are used for financing, investments, etc. So when I have a transaction that transfers funds from one of our accounts to another, that same transaction is entered once as an expenditure and once as an income for each respective account. I've created the script so that the transaction entered as an expenditure is imported to the income table, leaving 3 blank fields which need to be entered according to which account is recieving the funds. The choices of these 3 fields are made from drop down menus with script triggers set to move you to the next field once the selection is made. This streamlines the entering of data eliminating tabbing or mouse clicking between the fields. Once data is entered in the 3 fields a custom message allows you to choose to continue editing the record or to save the record and close the window, returning to the original window the script was run from to continue your work. I find it silly to have to press the continue button to resume the script. Also, unless there is a way of doing this I'm not aware of, once the script is paused you can continue to go on and do other things, further editing the record, close the window, exiting the script, etc., in which case you may be able to exit out of the script without recieving the final instructions or finishing the editing and saving the record properly. The 1 second loop seems to work very well as it doesn't let you move on until data is entered in the 3 fields. If there's an safer, more efficient way of doing this I'd love to know!

Hi Vaughn, I had a feeling your Loop suggestion was a good one and that I just didn't have enough experience to get it to work so I kept at it and found a solution: I have the script go to the first field that needs editing and create a loop which pauses every second if the last of the 3 fields are empty: Loop Exit Loop If[3rdField ≠ ""] If[3rdField = ""] Pause/Resume Script [Duration (seconds): 1] End If End Loop I have script triggers on the 1st and 2nd fields which are selections from a pull down menu so no need for tabbing between fields. As soon as a value is entered into the last field (or 1 second after) the script resumes, coming out of pause. With this solution I'm avoiding the tabbing between fields and the pushing of the Continue script button. But more importantly for me, whoever is editing the record won't be going through all the fields and perhaps editing other fields with the script is still paused, since it includes further instructions as to what should be done next. I am not a full time FM developer, having developed a solution (albeit rather extensive and complex) for my buisness so I've basically taught myself since v3 (besides all the great help I've had from this forum) so I may miss things that are just plain obvious for those of you who do this every day. Thanks again for your help, this is a great forum! Cheers, Alvise

OK - so OnObjectSave can resume a script, or push a button? How so?

I had tried that. It doesn't seem to work. If you could trigger the pushing of a continue button on modifying the last field that would work. Is that possible? If I split the script into two scripts I don't need the pause but it's not a practical solution. Thanks for your help.

I have a script that pauses for the user to modify 3 fields in a record. Is it possible to have the script continue without pressing Enter or clicking on a Continue button once the 3rd field is modified? Or is it possible to script the pressing of the Continue button? I can trigger the selection of a button upon modifying the 3rd field but that doesn't "press" it. I guess what I'm asking in general terms is if there is a way for a script to be paused until certain conditions are met and then resume without the user having to click anywhere or press the Enter key. Cheers, Alvise

I was hoping someone would say that! I've only recently began working with v11 and haven't gone through the documentation yet. It would be nice to be able to add layout variables from the Layouts menu - New Layout/Report though, in the headers and footers options. But I guess that would mean there would have to be an extra step for including the script trigger as well. Does this resolve the slowdown for large databases with calculation fields? With the calc field and a report with about 20.000 records (8-10 fields including summaries, grand totals, etc.), 1.132 pages, I notice only a very very slight delay (milliseconds) in generating the report compared to the layout variable solution, which seems almost instantaneous.

Nope. I don't use the report or print layouts to edit records or find or refine found sets. I do that in form layouts. Switch to the form, edit records and found sets then preview or print. Repeat until the report contains the exact info I want, with the right number of pages every time. If everything is right except the page count, just move out of the layout and back in and your done. It IS still a work around though. Filemaker should get their act together and fix it in the software...

"Simpler" may not be the best choice of word. Maybe more "flexible", because you don't have to rely on a script that will work on the layout before you select it. I have many buttons that are "goto layout" buttons, or I'll often choose a layout from the layout menu. Just choosing the layout will add the correct total number of pages, independantly of how you arrive at the layout. In addition, I'll often just want to look at a layout then work on the found set some more before printing to make sure I have the correct records, etc. This solution seems more "flexible" for that. I'll also admit the other way is more cumbersome to implement at least for me.