MogensBrun

Hi Søren, The first problem is to execute an AppleScript from a FMS server script. As stated above the script step "Perform AppleScript" can't be used in a server script. So a possible solution is to activate an AppleScript by using a shell command like 'osascript '. But even this roundabout will not start the AppleScript. I have checked that owner, group and permission for the AppleScript is set correctly to allow FileMaker Server to execute the Applescript. So the inability to execute AppleScript may be found elsewhere. If I could activate an AppleScript from FMS, the next problems would be to pass parameters between the FMS script and AppleScript, but these could be solved by writing parameters to a temporary file. Actuyally 'osascript' does now allow for sending parameters from a Shell command to Applescript. Regards, Mogens

Hello, I am trying to execute an AppleScript using a Shell command (via Troi File), because the "Perform AppleScript" command in ScriptManager is not server compliant. While I can execute other Shell commands I can't get 'osascript ' to work in a server script. It works as expected in a client script. Has anybody got success with calling AppleScript from a server script? Regards, Mogens

It will work if you are the only user of a solution. However, if "local.fp7" is the user interface (in a Separation Model) and there are a number of users, you cannot be sure that TOs in "remotel.fp7" to tables in "local.fp7" will work. If a user has renamed his harddisk, or any of the other folders in which "local.fp7" is stored, the TO in "remote.fp7" will break. It might work if it was possible to set up a relative reference from "remote.fp7" to a "local.fp7". Then you should only place the "local.fp7" or an alias to "local.fp7" in FileMakers application folder - or relative to this folder. As mentioned, the FileMaker Help file explains relative file references, but they don't seem to work from "remote.fp7" to "local.fp7". So therefore my conclusion: In a separation model it is not possible to access data in "local.fp7" from "remote.fp7" - unless you are the only user.

The "local.fp7" and the "remote.fp7" both belongs to the same solution. The "local.fp7" contains the user interface and no business data - only session data - while the "remote.fp7" has all the business data stored. Each user has his own copy of "local.fp7". I would like the "remote.fp7" to have access to some session data from each users "local.fp7". As mentioned, the Help file explains, that a remotely opened file will use the local FileMaker Pro directory as strarting point for a relative file path. So in theory one should be able to relate from "remote.fp7" to "local.fp7" using a relative file path. However, that doesn't work - at least for me.

From a local FileMaker file ("local.fp7") it is - of course - possible to relate to tables in a remote FileMaker file ("remote.fp7") through establishing the latter as an External Data Source in the first. However, the reverse is not true - at least to my experience. From the FMP 10 Help file "Creating file paths" description of relative file paths I would expect that something like "file:./local.fp7" would work as External Data source in "remote.fp7", if "local.fp7" is stored in the FileMaker application folder because "If the current database is opened remotely, the path starts from the local FileMaker Pro directory" (citation). But it doesn't work. So there seems to be no way for FileMaker 10 (or below) to establish a local file as data source for a remote file. Any suggestions?

Hi, Today I found another way of selecting font on Win and Mac platforms. Lets suppose we want to use Lucida Grande as standard for (most) fields and field labels on Mac while we want the file to display the same fields and labels in Tahoma or Segoe UI on Windows. This goal would actually give better design freedom than being forced to use a font, which happens to work on both platforms. The mentioned fonts are optimized to either platform (Ludida Grade is the prefered Leopar font, Tahoma is the preferred XP font and Segoe UI is the preferred Vista font). If we develop on Macintosh we just have to specify Lucida Grande for our set of fields and labels. When we open the file on the Windows platform this fields and labels will be shown with "unknown" font. Never the less a font is applied, and that font is specified in Preferences/Fonts/Specify Font when you select "Roman" input type. To get Lucida Grande (or other or the platform "unknown" fonts) to be displayed in Tahoma, you only need to select it as the "Western" (same as "Roman" on Mac) input type on the Windows platform. The same file has separate settings for input type for Win and Mac, so you can otherwise create fields and labels on Win with Segoe UI as font, and get it displayed in Lucida Grande on Mac if you similar select Lucida Grande here as the Roman input type. Note: In a newly created file the default font used for fields and labels will always be the font defined in Preferences to be used for Roman/Western input type. Conslusion: Platform specific font selection can be performed between one ( and only one) font to another font on the other platform - if the first font is “unknown” to the other platform. And vice versa. The drawback is of course that some fields and labels will show "unknown" font on the "other" platform, but as long the developer knows the rule it should have no practical consequences for the users. Note about Tahoma on Win: If you create a file on Win and selects Tahoma as main font, you can't get that converted to Lucida Grande on Mac, because Tahoma is a known font here. So if you want a change between Lucida Grande and Tahoma you must definitively develop on Mac. Mogens Brun FMintegrator

I have not seen the following method described before, so I will present it as a way to distribute any kind of file from a FileMaker server to connected clients. A typical example would be distributing a new version of a FileMaker interface file to all users of a FileMaker Server. (It is worth while to run FileMaker interface (or GUI) files locally on the client, while the data file(s) reside on the FileMaker server). 1. On the FileMaker server (Mac) all plug-ins to AutoUpdate should be placed in this folder: /Library/FileMaker Server/Data/Databases/AutoUpdate/. 2. Create a new folder inside the AutoUpdate folder to store the Interface file to be distributed to clients: /Library/FileMaker Server/Data/Databases/AutoUpdate/Interface/ 3. Create a folder inside the Interface folder with the version number of the FileMaker Interface file: /Library/FileMaker Server/Data/Databases/AutoUpdate/Interface/1.1/ (there may be a number of version files inside the Interface folder. 4. Make a zip copy of your FileMaker Interface file (right click on Mac an select compressed archive ... ). Rename the compressed archive to "Interface.fmplugin.tar". and place the renamed file in /Library/FileMaker Server/Data/Databases/AutoUpdate/Interface/1.1/Interface.fmplugin.tar (the name of the file must match the name given to the folder in (2)). ... 5. When you start your local Interface file then ask FileMaker server for a list of the available versions of the Interface file on the server by: [color:blue]FMSAUC_FindPlugIn ( "Interface" ). This command will return a space delimited list of all available versions of Interface file in the /Library/FileMaker Server/Data/Databases/AutoUpdate/Interface/ folder. Check that your local version matches the highest version of the server. If not, download the newest version. 6. Downloading of version 1.2 requires the command: [color:blue]FMSAUC_UpdatePlugIn ( "Interface 1.2" ). This command will download the zipped version of Interface file 1.2 and place it in /Users/MyName/Library/Application Support/FileMaker/Extensions/Saved/ in unzipped version and with its original name (example "MyInterface.fp7"). The datatransfer and unzipping is very fast. 7. Now you can use a helper file to close the current Interface version, move the new downloaded version from /Users/MyName/Library/Application Support/FileMaker/Extensions/Saved/MyInterface.fp7 to the same place as the old MyInterface.fp7 (and overwrite it). Then start the new version, and you will be running a new version without any user interaction. The file movement can be done by Troi_File or a similar plug-in. 8. I have not tested this procedure yet on the Windows platform but can see no reason for it should fail there. This method will allow you to download any kind of file from a FileMaker server to a client if you just disguise the file as a plugin. No ftp is required. Note1: You will receive a -1 error to the F[color:blue]MSAUC_UpdatePlugIn ( "Interface 1.2" ) instruction, because FileMaker can not finish installation of the downloaded disguised plugin. Which actually is quite acceptable when you really are downloading something else. Note2: The method described is for version 9. Best regards Mogens Brun FMintegrator

The [color:red]HTMLtoText custom function at Brian Dunning's site has been updated to 1.04. You may use web viewer, Troi URL or Fusion TCPdirect to capture the web page, and then parse the source HTML to formatted text. A demo file can be downloaded from this post. The custom function uses now three global fields. The reason for this is that: In FileMaker a text expression may either be (1) a constant - or "literal" - text string, (2) a field reference (either a normal or global field), or (3) a calculated combination of (1) and (2). Ad. (1) A constant is entered between quotes in a Set Field script step or in a Custom Function ... or similar. FileMaker's internal text editor will filter keyboard entered characters, so only a subset of the possible ASCII chars may be expressed. For example you can't enter a line feed (ASCII = 010). Ad. (2) Text in a field may be entered through keyboard (1), by import from other files or by import from a web viewer field. The two last methods make it possible for any ASCII value to occur in a field. ASCII-value NULL (0) seems to provoke a crash in some circumstances. Other ASCII-values can give other problems. These characters can't be entered in a constant/literal text string, but must be pasted into a field, if you want get rid of them through a substitution or similar. Dette er årsagen til at jeg er nødt til i HTMLtoText at benytte to globale felter til at repræsentere karakterværdier, der ikke kan indtastes mellem anførselstegn som literal tekst. Det drejer sig om ASCII = 010 og ASCII = 063, som jeg fandt ud af ofte gav problemer ved HTML parsing. Listen burde måske udvides med flere tegn, bl.a. ASCII = 000. There is an alternative metoh: Fusions TCPdirect plugin will allow you to express any char value. So by using this plug-in you can avoid to use globals for storing of special char values. Ad. (3) All above applies to this point. DemoHTMLtoText_1.04.zip

The [color:red]HTMLtoText custom function at http://www.briandunning.com/filemaker-custom-functions/ has been updated. You may use web viewer or Troi URL to fetch the page, you want to parse from HTML to text. A demo file can be downloaded from this post.

I recently posted a HTMLtoText custom function at http://www.briandunning.com/filemaker-custom-functions/, which can convert a whole web page or larger part hereoff from HTML to plain text - with preservation of bold, italic and bullet formatting. A demo file with this custom function may be downloaded from this post. Bedst regards, Mogens Brun DemoHTMLtoText.fp7.zip