Krioni

When files are selected for uploading using SuperContainer Companion plugin, it quietly takes any "file" that is a package/bundle in Mac OS X (essentially, directories that are treated as single files) and zips them. The problem is that when you use the function SCDownload in the plugin to allow the user to export/save a local copy of the file, it does not transparently decompress the ZIP file. Instead, they are presented with a file that is different than what was uploaded. I'm planning on a work-around where we store the real file extension upon upload. Then, when they click our scripted Export button, we will present them with a "Save" dialog that has the name and real file extension of the file. Then, we will export a temporary file to a temporary location, then unzip it from the temporary location to the location the user chose (using ScriptMaster). It's disappointing to have to do this kind of work-around. Am I missing something? Is there some setting in SuperContainer Companion that tells it to transparently store and export packages as the real package, instead of silently zipping, but then not distinguishing between files zipped ahead of time by the user, and files that were not originally zipped?

I love AppleScript, and have done a lot of work from FileMaker using it. However, there are downsides to using AppleScript, including: 1) returning a value requires hard-coding a field/layout/table name into the AppleScript code; and 2) if you are running more than one copy of FileMaker at a time, it can have errors. I have written custom AppleScript handlers to getFromFMP and sendToFMP that address both of those issues, but they still require having a special "AppleScript Data Transfer" layout with a global field on it. Running a shell script directly in a command that returns a value into a variable is much more concise, and less likely to break if you rename a field or layout or table. As you point out, though, the "quoted form of [somepath]" that AppleScript offers is extremely useful.

I'm glad you can reproduce it. It's a big problem for my client, since now he would have to downgrade Java (not trivial) or use a different machine to run what was supposed to be an automated process. All this because we thought auto-upgrades were a good idea. *chagrin* Any idea on how soon there will be an update that fixes this? It's a pretty frustrating bug, especially since using alternate ways of reading the file (BufferedReader, etc.) have the same crashing problem. Or, any idea on a work-around?

Well, the machine was upgraded to the newest version of Java. Now the plugin loads. However, an even worse problem now occurs: We use the Read File Contents function that came with ScriptMaster.fp7. I've noticed that on Windows XP SP3 (on two different machines), the function causes FileMaker Pro 10.0v3 to crash if we attempt to read in anything other than very small files. For example, a 433 kilobyte file is read without a problem, and the results shown in the ScriptMaster.fp7 file. However, a 525 kilobyte file crashes every time on two different machines. Also, I can no longer downgrade to ScriptMaster 3.1 on the machine with the upgraded Java, because when I tried, FileMaker crashes at the splash screen while loading the 3.1 plugin. I made sure only one plugin was in the various possible plugin folders. So, now that I've upgraded the Java on that machine, it appears that I MUST use the ScriptMaster 3.33 plugin, which appears unable to read a file of more than about 500 kilobytes. I even tried re-writing the Read File Contents function to use a BufferedReader rather than the very simple getText() function, but that also crashed under the same conditions. Any ideas? This is really interrupting my client's work. All for the sake of trying to be up-to-date using the auto-update feature.

I have a machine running Windows XP SP3. ScriptMaster 3.1 works without a problem on it. However, when it let it auto-update to ScriptMaster 3.33, the plugin is downloaded into the correct folder, but appears to be failing. Restarting FileMaker doesn't help. When I go to the plugin preferences in FileMaker and click on it, no version displays. When I then quit FileMaker and check the 360works log file, it has many errors. The log is included below. Checking the value of SMVersion returns "?" even though the plugin is in the correct folder (was put there by 360works AutoUpdate file) and the plugin is listed (and checked on) in FileMaker's Preferences -> Plugins. Checking the Java version returns: 1.6.0_15 Reverting manually to an older version of the plugin works without problem. Here's the log file entries:

Well, Yahoo isn't going to help you. You can look at the source code of their page to determine what info you need to send, in either an http GET or POST request (what web browsers do when you click a link). I've got a somewhat detailed explanation of how to post http forms on my website. Check it out and see if that gives you enough to do what you need. It's written for FileMaker and AppleScript, but the explanation should help, regardless of the tools you use.

Well, on Mac OS X you could use AppleScript code that calls a built-in command line utility called curl. On Windows XP, there may be some software you can run using the Send Event script step. If not, you can supposedly write your own code in BASIC or C and call that. There are also third-party plugins that allow you to call URLs (which is what you need) and put the resulting HTML code into a FileMaker field. You could then parse the code for just the piece you want.

There's a sample plugin that comes with FileMaker 8 Advanced that allows you to trigger a script when a user exits a field. There are also third-party plugins that do that. In your case, the easiest thing to do is to _start_ a script before data entry that loops over the following: New Record, Go To Field "ZipCode", Pause Then, you can enter a ZipCode, tab to next field if needed, etc. When you hit Enter, it should resume the script, creating a new record and going to the ZipCode field. PS. This is the behavior on Mac OS X with FileMaker 8. Windows may treat the Enter key differently. YMMV.

There is a way to do this, although you really should analyze your use to see if a related table would be better. Create a calculation field BLANK_REPEAT that is set to "" (or 0, if you prefer). Now, mark its repetitions (below the calc box in Define Field) to the maximum number of repetitions in the fields you want to blank out. Now, create a Number field called "ResetRepeat". Create a field called "_Default" (or whatever) that is a calculation equal to 1. Now, make a Relationship called "ResetRepeat" from the ResetRepeat field to the _Default field (new table occurrence). Make the Repeating Field you want to clear have an Auto-Enter that does a Lookup to the ResetRepeat relationship. You'll pick the BLANK_REPEAT field, and MAKE SURE you uncheck the "Don't copy if empty" (that IS the whole point), and set If No Exact Match to "Do not copy." Now, to clear that repeating field, you just set ResetRepeat to 1. You could obviously extend this in various ways to clear out other fields. I haven't done speed testing on this, but I'm assuming it's faster than a loop. If you speed-test it and it isn't faster, let us know here.

Well, there are many ways to do this, including use the Let function, a Custom Function (if you have Advanced), etc. Here's one way that works: Middle( SomeTextField ; Position( SomeTextField; """; 1; 1) +1 ; Position( SomeTextField; """; 1; 2) - Position( SomeTextField; """; 1; 1) -1 ) Where SomeTextField is your source text. Also, you'll guess that you could do the same for any other substring. Note: this will find the FIRST double-quote character and get text between that and the SECOND double-quote character. If you wanted to get multiple quoted pieces from one string you'd need a lot more code. At that point, you'd certainly want to use the Let function or a Custom Function.

FileMaker Pro 4.0v3 in Layout Mode (running in Classic environment) has a really strange behavior: When dragging an object, the object's outline drifts away from the cursor, while the object itself stays where expected. The problem is, this makes it very hard to place on object where you want it. I haven't tried this in FM5 yet, but most of my clients are still running 4.