Haynes

YES! Thanks Fenton. That works as a Perform AppleScript step. It all boiled down to that missing "to" in front of the "open" command.

Irrespective of paths and applications, there is a problem with this syntax. When executing the listed code, the following dialog appears: "Expected end of line but found command name". Clicking OK yields a dialog of: "Unknown Error: -2741." Suggestions? Thanks.

I have a bunch of differently named PDF files, each corresponding to a record in an FMP 7 database (Mac) called "testinglinks". For each record, in addition to providing data relating to the corresponding PDF file, I want to be able to open that particular uniquely named PDF file via a scripted button based on the field containing the PDF file's unique filename. The name of that field is "testinglinks:imagefile". I have tried using a calculated Send Event utilizing the PDF default application Preview to no avail, even after playing with pathnames ad naseum. I have also made a rough attempt using lots of variations on a calculated AppleScript, again meeting failure. Those attempts spring from the following suggestion by Fenton: "tell app "Finder"�" & "open " & """ & testinglinks:imagefile & ""�" & "end tell" It does not seem to matter where I place the PDF file(s) on my local drive, including at the top level, on the User's Desktop, in the FMP7 folder, or anywhere else. Suggestions? Thanks.

I need to tap the collective wisdom re: good ways to provide FM database access to remote users who will be entering data, searching, etc., and possibly modifying the structure of the database (adding or modifying tables, fields, calculations, scripts, etc.) The remote users will be one of the following flavors: 1) running FMP7 on a desktop OSX Mac or Windows XP machine from home with high speed Internet access; or 2) running FMP7 on the road with a OS X Mac or Windows XP laptop and who knows what access speed (but will have a Sprint Vision cell phone account). The database of interest is currently hosted via FMP7 peer-to-peer sharing on an eMac (1.25Gz G4, 768MB of DDR SDRAM, relatively fast drives) dedicated to serving the database and lots of files to about 4 concurrent users all running FMP7 and OSX and connected via a 100Mbps ethernet LAN that sits behind a firewall running on a Dual-WAN router coupling the LAN via both a DSL modem and a cable modem (each with a dynamically assigned IP address) to the Internet. I have also recently obtained a low-end Dell 3000 (P4, 2.8GHz, 512MB DDR SDRAM, 80GB Ultra ATA 7200RPM hard drive) that I hope to connect to my LAN to serve PC applications to the Mac users via a remote control program such as Timbuktu, Microsoft

Thanks so much Queue. Both approaches work. I have implement them as: Case (Evaluate( "Get(ActiveFieldName)"; [field1; field2; field3;...;fieldN] ) = "field2"; "The current field is field1"; Evaluate( "Get(ActiveFieldName)"; [field1; field2; field3;...;fieldN] ) = "field3"; "The current field is field2"; [etc.];"") where the phrase "The current field is field1" can instead be the help message for the appropriate field, or whatever other text is desired. If I set the tab order for the layout, and insert an otherwise unnecessary field1, this approach, although awkward, just might fulfill the objective, provided (as you helpfully warned) that data is entered or edited in the previous field. If data is not entered, the calculation is not evaluated and no help message appears. In any event, I will try this approach as well as the suggested Help button approaches to see which is ultimately more practical for my users. Thanks again.

Upon re-reading your post, Queue, I see that you mentioned that Ugo has found a way to return the previously entered field via an unscripted calculation. I think I can work with that, considering that my user will likely visit the fields in a predetermined sequence. Can you post his method? Thanks.

Thanks for the replies. Both are very helpful. I hear you Queue that Get(ActiveFieldName) does not currently work in MOST calculation fields. Will it work in any? If so, perhaps I can manipulate it to my suit my goal. If not, I still tend to believe that that Get(ActiveFieldName) or a similar FileMaker-provided function SHOULD work in principal for what I'm trying to do, for at least 3 reasons. First, FMP7 can detect that the cursor has entered a particular field, and certainly knows the identity of that field, since it can activate a pop-up list of data choices that it knows are assigned to that field. So why can't FMP7 provide the identity of that field to me? Second, FileMaker makes Get(ActiveFieldName) visible and available in the Calculations dialog and does not limit its visibility and availability to ScriptMaker. Thus, Get(ActiveFieldName) should work in calculations. Don't tease me, FileMaker. Third, FileMaker's help materials provide no indication that Get(ActiveFieldName) won't work in calculations, thus suggesting that it was intended to work in calculations and that its current non-functional status is actually a dysfunctional status, i.e., a BUG, which FileMaker should promptly exterminate Off the soapbox. Other than using scripting, is there any way to use a pure calculation to solve my goal of providing a help message that is specific to the field the cursor is currently in? Is there any way to make Get(ActiveFieldName) work in ANY unscripted calculation? Thanks.

What I'm trying to do is provide a user with a help message for the field in which their cursor is located, the help message providing a tip about how to complete the field. I would rather not place the user in a scripted loop throughout the entire data entry process. The first thought that comes to mind is a calculated field that relies on Get(ActiveFieldName) to select what help text to display. Can anyone post an easy unscripted way to solve this particular problem? It is completely escaping me how to do it other than with the Get(ActiveFieldName) command, which shamefully does not work correctly (intuitively?) in anything other than a script. I know, I know, it's a feature, not a bug. Rrriiight. Thanks.

> If the script will be used on multi-user FMP7 databases, instead navigate to > the "Users" folder and then to the "Shared" folder.... But the shared folder > is likely (but not guaranteed) to be: > "Macintosh HD:Users:Shared:" > So that's your best hope, as you must hard-code this into the FileMaker. Fenton, for multi-user FMP7 databases, there appears to be a slight variation on your suggested approach, as well as a more significant variation, that in some situations might work better. For the slight variation, after navigating to the [localdrivename]:Users:Shared folder when creating the script, change any AppleScripts to refer only to "Users:Shared" and not mention the local drive's name. This seems to be helpful when not all local drives of the users have the same name, i.e., "Macintosh HD". For the more significant variation, if a shared volume (e.g., an AppleShare volume) is accessible and/or mounted by each of the users of the multi-user ("shared") database, FMP7 can consistently save the PDF file for each user to a location on that shared volume, so long as the path (including the volume name) to that location does not change. I am not certain, but this might be helpful in a mixed (OSX + other OS's) environment. Thus, step 1 of my suggested procedure above should be revised to read: 1. In FMP7, to automatically save the current set of records using the current layout as a PDF file: a. Create an FMP7 ScriptMaker script containing the "Print" step. b. For that script step, place a check mark in the check box for "Specify Print Options". c. Click on the "Save as PDF..." button. d. For a single-user database, navigate to the "Desktop" folder of the local drive. e For multi-user databases, instead navigate to either: 1) if a shared volume is available, a commonly-accessible, fixed-named location on that shared volume; 2) if a shared volume is unavailable, a commonly- and fixed-named location on each user's drive, assuming each drive has the same name; 3) if a shared volume is unavailable and there is variation in the names of the users' drives, to a location that is commonly- and and fixed-named (other than the drive name), such as [localdrivename]:Users:Shared folder. (Note: modify the remaining AppleScript instructions of this procedure to refer only to "Users:Shared" and not mention the local drive's name.) e. Click the "Save" button. f. Click the "OK" button to save the script. g. Go to the selected location and find the saved PDF file. It will likely have a name of either the name of the database or "Edit Script" followed by ".pdf". h. Make note the name of that file and delete it. Note: for this first invocation of the script, that particular PDF file might not be openable by Preview or Acrobat. I look forward to any questions, corrections, or alternative approaches. Thanks.

For those looking for a much less-sophisticated, OSX only, solution, see post 141081 and its thread, which describe how to do automatically "Save as PDF..." using only FMP7. That post also describes how to set the desired name and location of the resulting PDF file using very simple AppleScripts.

For OSX only, post 141081 describes how to do automatically "Save as PDF..." using only FMP7 and AppleScript. It also describes how to set the desired name and location of the resulting PDF file.

Great insights, Fenton. Thank you. I plan to implement them in my current FMP7 project. To summarize, one can generate AppleScript from FMP7 aimed at, e.g., the Finder, via either "calculated" AppleScripts or via "native" AppleScripts. For static values (e.g., origin filename, origin path, destination path, etc.) and simple scripts, either way will probably work well. For more complex scripts that use FMP7 fields for variables, I much prefer Fenton's approach of "setting" each of the FMP7 fields to AppleScript variables using "native" AppleScript rather than "calculated" AppleScript, which is indeed a pain to write. Also, I particularly appreciate the "path to 'sdat' as string" suggestion. Very helpful. Thanks again.

Thanks Fenton. You are correct, and your posts did help me find a way to accomplish my goal. Despite Fenton's laudable and much-appreciated help, for one who has not scripted much in the past few years (but man did I have fun in '87 when Apple introduced HyperTalk -- since renamed AppleScript), I did find developing the desired AppleScripts to be incredibly difficult and frustrating. Thus, I deeply hope Apple gives its overly neglected step-child some much needed TLC in the very near future (perhaps a la Tiger's Automator?), so that it again becomes the programming language "for the rest of us". In any event, so that my pain and loss of precious time is not repeated by everyone with a similar FMP7 objective, here are a few minor clarifications/tips for those like myself who are somewhat scripting-challenged: 1. In FMP7, to automatically save the current set of records using the current layout as a PDF file: a. Create an FMP7 ScriptMaker script containing the "Print" step. b. For that script step, place a check mark in the check box for "Specify Print Options". c. Click on the "Save as PDF..." button. d. For the local drive, navigate to the "Desktop" folder. If the script will be used on multi-user FMP7 databases, instead navigate to the "Users" folder and then to the "Shared" folder. e. Click the "Save" button. f. Click the "OK" button to save the script. g. Go to the Desktop (or Users:Shared) folder and locate the saved PDF file. It will likely have a name of either the name of the database or "Edit Script" followed by ".pdf". h. Make note the name of that file and delete it. Note: for this first invocation of the script, that particular PDF file might not be openable by Preview or Acrobat. 2. If you want to automatically rename the PDF file, you can do so via an AppleScript. a. A very simple version of the "Rename this file" script can read: tell application "Finder" set name of file "Your Disk:Users:Roxanne:Desktop:foo.pdf" to "test.pdf" end tell b. To generate a similar AppleScript from FMP7, using a dynamically-generated origin path, origin filename, and destination filename (specified in FMP7), you can create the following calculated AppleScript in FMP7's ScriptMaker: "tell application " & Quote("Finder") &

If one is using OSX (10.3) and FMP7, is there a way to script the automatic creation of PDF's from FMP7? That is, can one completely automate the process of: 1. Choosing "Print..." from the File menu; 2. Selecting the "Save as PDF..." button; 3. Naming the PDF file with the desired file name; and 4. Navigating to the desired folder (or after saving, moving the file to the desired folder); so that one can click on a button in FMP7 (or otherwise invoke a script) and have a PDF automatically created for the currently displayed record(s) using the current layout in the location and with the filename specified in the FMP7 database? I've found a way to do it with a combination of QuicKeys 3 and FMP7-generated AppleScripts, but not using purely FMP7-generated AppleScripts (which is my preference). I currently use QuicKeys 3 for steps 1-3. If you know of a way to make FMP7, via AppleScripts only, automatically perform steps 1-3, please advise. Thanks!