Mikhail Edoshin

DDR Viewer is a lightweight browser for FileMaker Database Design Reports. It displays DDR data in clear non-cluttered lists of properties and references, set in a large readable font with color coding to see the difference between a reference, a constant, or a calculated expression. With DDR Viewer you see all important properties, don't see unimportant ones, quickly jump to a referred element with a keyboard shortcut, and quickly go back to where you were. DDR Viewer lists all references to an element, all missing references and also tells you where it falls short so you can check these places manually. DDR Viewer is fast, simple, inexpensive and is available immediately at http://www.onegasoft.com/ .

Try to access the same URL using some other tool, e.g. curl. Some servers check the "user agent" header and return different content to different agents. Also: is this a HTTPS resource, perhaps? Safari would access it just fine, but FileMaker won't, as far as I know.

I normally identify workstations with a little file I export in the Preferences folder and then import back at startup.

No, it should work out of box provided the target application implements a DDE server that understands the DDE Execute call and has "SendMessage" as possible Topic. I don't know what Page Master is, unfortunately. As far as I know DDE is considered old-fashioned and is probably a rare beast in modern applications.

emSoftware has two other plug-ins for database publishing: InData and InCatalog. Both can work with exported data, ODBC connection, and InCatalog also seems to work with FileMaker live (under Mac OS X only).

There are two plug-ins for Quark XPress and InDesign: XCatalog and InCatalog. As far as I know under Mac OS X they can work with live FileMaker files. They are especially designed for catalog publishing. http://www.emsoftware.com/products/xcatalog/features/ http://www.emsoftware.com/products/incatalog/features/

Yes. The script should look like that: Enter Find Mode[] Set Field[ Modified On, ( Get( CurrentDate ) - 4 ) & ".." & Get( CurrentDate ) Perform Find[]

There's no way to place XSLT code there; it must always be a file stored on a disk or hosted on a web server. The calculation here is meant to specify the path to the file or the http request dynamically.

You can automatically download and update client plug-ins from server. This requires a bit of coding, i.e. you should use special functions provided by the AutoUpdate plug-in (included) to see if you have a new version on the server, then get it and install. Under Windows you can also use shell commands to work with files with the Send Event script. E.g. "cmd /C move " & fullPathToSource & " " & fullPathToTarget. This is harder than using a special plug-in, because to have solid code you should check for errors and the only way you can do this is to redirect output and error into files (using code like "1>output.log 2>error.log"), then import these files and see if the operation was successful. Doable, but I myself would prefer a plug-in.

To do this with two windows you'll have to script navigation so each time you change the current record, the script would switch to the second window, find the record there and switch back. A simpler way would be to use one window and to place all the fields from the details view in the header or footer part.

You can get contents of a summary filed using the GetSummary() function and then format them as necessary.

I'd rather add a separate table to keep multiple revisions of these text fields. Each revision would have a serial number to print on the report. After printing the revision would get locked in such a way that ordinary users cannot change it. If it's necessary to edit the report, the system would add a new revision (duplicate the last one) with a new number.

To me the best solution is not to use maximized windows under Windows. I normally make my main window slightly smaller than the available screen space (about 50 pixels less at both dimensions). This makes it simple to open and manipulate multiple windows.

The script with two requests “> 2/01/2008” and “< 2/20/2008” will actually find “ > 2/01/2008” OR “< 2/20/2008”. A correct way to search for date range is to use the “..” operator: 2/01/2008..2/20/2008 It's inclusive, i.e. end dates are also included. In modern versions if the date range is exactly a month or a year, it's possible to use a wildcard like: 2/*/2008; */*/2008.

You pass field values as usual, but you use global fields. To successfully set a value of a global field in a web session you need to tell FMS the filed is global, so if the field name is “A” you use “A.global”: ...&A.global=first criteria&B.global=second criteria&-script=Adjust Find&-findall The “Adjust find” script enters find mode, creates correct find requests with values from A and B fields and performs find. The result goes to the browser.