comment

The only thing that comes to mind is detecting sales people submitting false figures - as explained here: https://en.wikipedia.org/wiki/Benford's_law#Accounting_fraud_detection

You cannot enter calculations into find criteria directly. You must do: Enter Find Mode [ ] Set Field [ YourTable::Datefield; Year ( Get ( CurrentDate ) ) ] Perform Find [ ] Or do: Set Variable [ $thisYear; Value:Year ( Get ( CurrentDate ) ) ] and then use the variable as the find criteria in your find request. --- P.S. Please edit your profile to reflect your version and OS so that we know what you can use.

See if the attached demo helps. ValueListStepper.fmp12

I don't know. I am still on v.18. I have seen some bug reports regarding this function and its associated symbol. Meanwhile you can use the old method of entering Preview mode, going to the last page and getting the page number.

I have seen a similar requirement a few times before, but not with a footer. Usually the requirement is to print some information at the bottom of the last page - which is not necessarily the 2nd page. It seems you're confident there will never be a 3rd page. Anyway, I don't know of an easy solution to either. The best I have seen is similar to your idea: place a shrinking global field in the Trailing Grand Summary part and add carriage returns until the page count increases to 2. This can be made more efficient by starting at some maximum and moving down by powers of two.

Some more details would be useful - e.g. is this a list report? What parts does it have? Why is it necessary "to print a second page in order to print the footer"? Do you have a title footer on the first page? And are you actually printing or saving to PDF?

I believe the answer is no. If you have objects in a portal row that occupy a certain height, and you make the portal shorter than that height, some of those objects will be cut off and scrolling the portal will not reveal the missing parts. What would be the purpose of this anyway?

I still don't see why you're creating the new record. If I understand correctly, you should be doing: Set Variable [ $ticketID; Value: Ticket::TicketID ] Set Variable [ $folderPath; Value: "Scans/" ] Go to Layout [ Ticket Attachment ] Import Records [ Folder Name: $folderPath; File Type: Picture and movie files; Target: “Ticket Attachment”; Method: Add ] Replace Field Contents [ Ticket Attachment::TicketID; $ticketID ] The import Records step will create a new record for each file in the Scans folder. The Replace Field Contents step will make the entire imported set related to the orig

Why don't you start with something simple: Place a folder named Scans containing a few PDF files next to your FMP solution file, then run this script: Go to Layout [ YourTargetTable ] Set Variable [ $folderPath; Value: "Scans/" ] Import Records [ Folder Name: $folderPath; File Type: Picture and movie files; Target: “YourTargetTable”; Method: Add ] Note that this will create an individual record for each file in the Scans folder. Your target table needs to have a container field to which you will map the image, and optionally fields for file name, file path and thumbnail which the i

IMHO, images taken at the same event should NOT be cross-referenced to each other, but to the event. Assuming that you want to enable multiple references for the same image, I would expect to see a table of Collections and a join table between Photos and Collections. Thus all images taken at the same event are related to the same event - and it's an easy hop from any single image to all the other images related to the same event (or any other record in the Collections table that "anchors" related images together).

I don't see how the result can end with a <p> - unless you have two carriage returns before "Font: ". Such possibility raises other questions, for example: can there be more than two? And also: can there be more than one consecutive carriage returns within the message - and if so, should they be preserved? If the only issue is a possible single trailing carriage return in the extract message, you could do: Let ( [ lineStart = Position ( PASTED_INPUT_to_use ; "¶Message: " ; 1 ; 1 ) ; start = lineStart + Length ( "¶Message: " ) ; end = Position ( PASTED_INPUT_to_use ; "¶Font: "

I really don't know what could be the cause of this. It worked for me (on a Mac) without doing anything. Perhaps it's a Windows thing?

It won't work.

Well, as I said, I cannot reproduce the problem so I don't know what to look for. Does this happen with every file on your system or just this one?

See the attached demo. IslamicCalendarAPI.fmp12