Steve St-Laurent

I'm running into a problem with scripted export of contents of a container field in FMP 12 where the store is externally hosted in the default external storage location. Export works properly with a right-click export in the field but errs [unknown error: 20403] when I try to script the same thing. It's not a paths issue because the script works perfectly when the storage is changed to internal. Any tricks or gotchas to this new external storage for containers?

I just updated my Actual Technologies ODBC driver for open-source databases. Before the update I was able to store the login information so that users going to the external tables weren't prompted for a password. It was stored in the ODBC connection on the FM Server machine. Now every user gets prompted for username/password. Any ideas?

On more than one computer running OS 10.5.8 I'm seeing more crashes with FMPA 11 than with 9 and 10 combined. The triggering event seems to be going too quickly to a menu after closing the Manage Database dialog box. It happens both with local files and with ones hosted on FM Server. Anyone else running into this?

I can vouch for the GetAsCSS function for preserving text field formatting when published via the Filemaker PHP API. Use it extensively in Web content management stuff. Don't know what I would do without it, other than manually insert HTML tags.

Ever since the Leopard upgrade to 10.5.8, new cross-platform printing scripts I create on the Mac are failing on Windows clients. Existing ones continue to print OK. Page set-up is for "Any Printer," which has always been my ticket for x-plat printing. Script goes through the standard print set-up, preview mode, pause then continue to a print dialog box. But the print dialog box doesn't appear on the Win machine. Mac prints exactly according to script. Scratching head vigorously . . . Any ideas here?

This was indeed the culprit. Setting the default mail format pref to plain text cleared it up. Thanks!

Out of the blue, a Windows XP SP2 machine that was nicely handling a print PDF and attach to email script is now attaching a file with a .DAT extension, instead of .PDF. Mail client is Outlook. Script has worked perfectly on this machine for more than a year, so I'm guessing it's some Windows or Outlook setting that has changed. The file generated is valid PDF; change the extension and it opens properly. Anyone encounter this?

The title pretty well says it all. Since applying the updater, I'm getting no server statistics. Checked the Logs folder, and the logs are in fact being written. They just don't display in the admin console.

What I'm trying to do is perform a user-defined Web search on a selection of text. Works great for text fields using the Get functions described above. It's all triggered by a button click. In the case of a Web viewer, you lose your selection as soon as you click the button. See the problem? I can use the GetLayoutObjectAttribute function with the "content" attribute, but it will return the entire Web viewer content, not a selection.

Is it possible to grab a highlighted selection in a Web viewer then have FM 8.5 pass that string to a search engine. I've got this working fine with FM's own fields but can't seem to make it happen with Web viewers. FM's Get(ActiveSelectionStart) and Get(ActiveSelectionSize) both require a field as a starting point.

A slip in good development practices forced me to go to resort to my FM7 runtime file as continuing point for development. It had custom About, Scripts and Help menu items. Is there any way to restore the Filemaker defaults? Also, does the fact that these were modified at one point rule out renaming them in a new Custom Menu Set?

A "New Window" script step [FMSA 7.03 Win/Mac] consistently gives me the contents of that alleged new window in the existing browser window. If I put a "Close Window" button in that window, however, that new content disappears/closes to reveal the referring page content beneath it. But if you use the browser's Close Window, everything closes, just as you would expect. Summary: On either Mac or Win FMSA, using IWP, I have never seen a New Window script step produce a new browser window.

Is FM7 IWP's handling of check boxes as pathetic as it appears? I have a solution with user-defined values and check boxes. Because the values are user-defined, there is no fixed number. So far so good. When displayed via IWP the check boxes are all over the place. It pretty goes box-value-box-value-box-value, wrapping the stuff as if it were mere text. On small stuff, with just a few choices, I've learned that you can put several iterations of the field on the layout, each with its own value. But obviously this won't work with an unknown number of unknown values. Is this where IWP rubber hits the pavement?

Really? I've been unsuccessful at any attempt to use the CDML2XSL tool. Doesn't matter

OK, I'm going to answer my own post . . . What I forgot to mention originally was that the button was, in fact, a global container from a related table of globals. In regular FM7 you can use these as buttons, provided you don't alway entry into them in either browse or find mode. It gives you a handy way to "skin" your file

I use portals extensively in desktop solutions but I'm having problems getting a button in a portal to properly go to a related record. For example, Companies is related to Contacts via a company-link field with contact records appearing in a scrolling portal. The portal includes a button to go to related record. It does go to one of the related records and it does appear in the correct layout, but it's often not the record in the row that has been clicked. Works flawlessly in dozens of Filemaker desktop solutions but not on the Web. I've tried every imaginable combination of Commit Record. Have checked all scripts for Web compatibility, even tried simplified scripts that simply GTRR and Submit to get a redraw. But no luck. Very frustrating because IWP's handling of the file is otherwise excellent. Any ideas here? TIA