From 360Works Product Documentation Wiki
(Difference between revisions)
Jump to: navigation, search
(Issue with deleting files stored in SuperContainer)
m (Usage tips)
Line 631: Line 631:
Example:  http://yourServer/SuperContainer/Files/path/to/files?style=applet&width=250&height=275
Example:  http://yourServer/SuperContainer/Files/path/to/files?style=applet&width=250&height=275
===Storing the filename of an uploaded file in a FileMaker field===
===Storing the filename of an uploaded file in a FileMaker field===
Line 710: Line 709:
===Moving SuperContainer Contents to a New Location===
I've deployed SuperContainer to one location, and now I need to move SuperContainer, along with all of the associated assets, somewhere else. What's the best way to do this?
* Move the Files directory
If you have access to the SuperContainer "Files" directory, the easiest way to move assets is to simply move the SuperContainer/Files/ directory to your new SuperContainer location. Upon deploying and configuring SuperContainer at the new location, SuperContainer will create a Files directory at the base URL you specify. Replacing this Files directory with the existing directory will maintain all of the assets and relationships from the current deployment.
* Use the Companion Plugin
After setting the base URL at the new location, using SCGetContainer to retrieve the SuperContainer asset from the old location.  Then use SCSetContainer to upload the asset to the new deployment location. You'll likely want to embed this in a looping script that will iterate through all of the SuperContainer assets. You can view a [ video about this process here.]

Revision as of 17:25, 5 November 2012



Limitations of demo mode

While running in demo mode, SuperContainer Server will run for two hours each time you start it. If the demo period expires, you may simply quit and restart the SuperContainer Server to renew the two hour demo period. When you are ready to purchase a license, just replace the demo license key with your permanent license key to get rid of the two hour timeout.

Cost / registration for plugin

There is no cost for the plugin; it is included with the purchase price of SuperContainer. There are no registration functions necessary.

Upgrading from Workgroup to Enterprise

If you would like to upgrade from a Workgroup license, first purchase an Enterprise license, and then contact us and we will credit the original charge for the Workgroup license. We are planning on upgrading our online store at some point to make this a more automated process.

Deployment and installation

How to install plugins for various configurations

See Plugin installation

What is the best way to get up and running with SuperContainer

Use SuperContainerServer.jar if you just want to put together a proof of concept, or if you're demoing SuperContainer. The standalone mode is also great to use while developing.

Manually Installing SuperContainer 2.0 and higher

SuperContainer 2.0 comes with a bundled installer. If you'd prefer to install manually, you can do the following:

  1. Determine your INSTALLATION_PATH
    • FMS12 on OS X: /Library/FileMaker Server/Web Publishing/publishing-engine/jwpc-tomcat/
    • FMS11 on OS X: /Library/FileMaker Server/Web Publishing/publishing-engine/cwpe-tomcat/bin/
    • FMS10 on OS X: /Library/FileMaker Server/Web Publishing/publishing-engine/cwpe-tomcat/bin/
    • FMS9 on OS X: /Library/FileMaker Server/Web Publishing/publishing-engine/cwpe-tomcat/bin/
    • FMS8 on OS X: /Library/FileMaker Server/Web Publishing/jakarta-tomcat/webapps/
    • FMS7 on OS X: /Library/FileMaker Server 7/Web Publishing/jakarta-tomcat/webapps/
    • FMS12 on Win: C:\Program Files\FileMaker\FileMaker Server\Web Publishing\publishing-engine\jwpc-tomcat\
    • FMS11 on Win: C:\Program Files\FileMaker\FileMaker Server\Web Publishing\publishing-engine\cwpe-tomcat\bin\
    • FMS10 on Win: C:\Program Files\FileMaker\FileMaker Server\Web Publishing\publishing-engine\cwpe-tomcat\bin\
    • FMS9 on Win: C:\Program Files\FileMaker\FileMaker Server\Web Publishing\publishing-engine\cwpe-tomcat\bin\
    • FMS8 on Win: C:\Program Files\FileMaker\FileMaker Server\Web Publishing\jakarta-tomcat\webapps\
    • FMS7 on Win: C:\Program Files\FileMaker\FileMaker Server\Web Publishing\jakarta-tomcat\webapps\
  2. Copy the SuperContainer folder to your INSTALLATION_PATH. Only copy the directory called 'SuperContainer', not the entire SuperContainer_2.0 directory.
  3. Modify the tomcat configuration files to serve SuperContainer content on port 80
    1. Determine your TOMCAT_CONFIG_FILE path
      • Mac OS X (for FMS12): locate mod_proxy.conf in /Library/FileMaker Server/Admin/admin-helper/WEB-INF/conf/
      • Mac OS X (for FMS11 and below): locate mod_jk.conf or mod_jk_paths.conf in /Library/FileMaker Server/Admin/admin-helper/WEB-INF/conf/
      • Windows: locate file in C:\Program Files\FileMaker\FileMaker Server\Admin\admin-helper\WEB-INF\conf\
    2. Add the appropriate lines to mount the SuperContainer webapp

Mac OS X (for FMS12):

ProxyPass /SuperContainer ajp://
ProxyPassReverse /SuperContainer ajp://

Mac OS X (for FMS11 and below):

JkFmMount /SuperContainer/* cwpe
JkFmMount /SuperContainer cwpe

Windows (for FMS12):


Windows (for FMS11 and below):


After saving your changes, restart your web service and all associated services (tomcat, IIS, FMS). Restarting your computer will work as well. SuperContainer should now be up and running!

Manual Tomcat deployment/update(Windows)

  1. Download latest SuperContainer form
  2. Extract the downloaded zip
  3. Stop Tomcat, either using the 'badge' icon in the bottom right corner on Windows, or by stoping service.
  4. Copy the SuperContainer folder
  5. Paste the folder into tomcat's webapps directory, usually it's located in c:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps. If the SuperContainer folder already exists there, then first backup the existing folder, then paste the folder from clipboard, then replace the SuperContainer\WEB-INF\web.xml file with one form the backed up folder, web.xml file contains customized settings.
  6. Start Tomcat, test the deployment.

Using port 80 with standalone SuperContainer deployment

In order to use the standalone SuperContainer applet, which by default runs on port 8020, on port 80 you will need to configure some settings within your Apache Tomcat server.

First, you will want to navigate on your machine to the Apache httpd.conf file:

Mac OS X:


NOTE: This may be hidden on Mac OS X and can be reached by using "Go" -> "Go To Folder..." in the Finder.


C:\Program Files (x86)\Apache Software Foundation\Apache2.2\conf

Now, add the following two lines to the httpd.conf file after the appropriate "DocumentRoot" as shown below:

DocumentRoot "/Library/WebServer/Documents"

ProxyPass "/SuperContainer" "http://localhost:8020/SuperContainer"
ProxyPassReverse "/SuperContainer" "http://localhost:8020/SuperContainer"

The ProxyPass and ProxyPassReverse are two Tomcat directives that allows remote servers (SuperContainer in this case) to be mapped into the space of the local server (Tomcat). You can find more information on these directives by visiting:

Then, you will need to restart your Apache server:

Mac OS X:

Open Terminal and type:

sudo apachectl restart


Easiest way to control Tomcat on Windows is to use the Tomcat Monitor tool. This is available by selecting Start -> All Programs -> Apache HTTP/Tomcat Server -> Monitor Apache

Finally, launch the standalone SuperContainerServer.jar file as normal and navigate to:


to ensure SuperContainer is running on port 80.

SuperContainer for hosting providers

You can run SuperContainer version 1.72 or later for your clients in Tomcat by following these steps:

  • Each client will need to purchase a separate license of SuperContainer, or you may purchase a license for them.
  • Modify SuperContainer/WEB-INF/web.xml file and put in valid values for the 'activationCode' and 'registeredTo' settings for your client.
  • Change the name of the SuperContainer folder to that client's name and put it into the webapps folder. The URL will become whatever you name the folder, so if you change the folder name from 'SuperContainer' to 'ClientX', the URL to access SuperContainer will be http://yourServer:8080/ClientX/Files.

List of hosting providers

The following companies have told us that they are set up or willing to configure their servers to host SuperContainer. They are listed in order of when they first contacted us:

Enabling OS X Core Image resizing

In it's normal configuration, SuperContainer can generate thumbnail images of JPEGs, PNGs, GIF files, and most TIFF files. It will not generate thumbnails for PDF files, CMYK JPEG or TIFF files, RAW files, or Photoshop files.

There's a mac-specific feature that lets SuperContainer use native OS X image processing libraries for its image handling. This means it can generate thumbnails of PDFs, as well as just about any other image type you throw at it. This only works if you're running SuperContainer server in standalone mode on an OS X box. It will not work on a Windows server, or when running in Tomcat. It doesn't matter what the client machines are using, however.

Just create a new file at the following location:


The contents of the file should be the following line:

coreImageEnabled true

And then restart SuperContainer. Thumbnails will now be generated using OS X image libs, and PDF will appear as thumbnails instead of icons.

Plugin auto-update info

See the section on Plugin autoupdate

Compatability matrix

Accessing SuperContainer from FileMaker Pro

  Version 7 Version 8 Version 8.0v4 Version 9 Version 10 Version 11
FileMaker Pro: Access with a Web Viewer X X Y Y Y Y
FileMaker Pro: Using optional plugin Y Y Y Y Y Y
  Version 7 Version 8 Version 8.0v4 Version 9 Version 10 Version 11
FileMaker Pro Server, Custom Web Publishing X X X Y Y Y
FileMaker Pro Server Advanced, Instant Web Publishing X X Y* Y Y Y
FileMaker Pro Server Advanced, Custom Web Publishing Y Y Y* Y Y Y

Note: * = FileMaker Server / Server Advanced 8.0v4 on OS X will not work with the optional SuperContainer Companion Plugin. It will work on Windows, or on 8.0v1 - 8.0v3

SuperContainer is fully compatible and tested to work with FileMaker 10

Configuring where SuperContainer saves files

By default, SuperContainer saves files in /Users/Shared/SuperContainer on Mac OS X and C:\Documents and Settings\SuperContainer on Windows. You can set this to any path you want, such as an external drive or network volume. If you are running in standalone mode (ie. double-clicking on SuperContainerServer.jar), that can be configured by clicking 'options'. If you are running in Tomcat or with FileMaker Server, you can configure that by editing the SuperContainer/WEB-INF/web.xml file. Change the 'macintoshFilesPath' or 'windowsFilesPath' setting to where you want the files to be stored. Be sure to configure file permissions appropriately for the folder you're storing to, especially for network volumes.

Locking the SuperContainer Registration

Entering information in the .../SuperContainer/Registration page will set your registration, but it can be changed from that page as well. If you want to lock in the SuperContainer registration so that it cannot be changed from a browser you should enter your license key in the activationCode and registeredTo values in the web.xml file (the same place you can set a username and password). Enter your values, save the file, and restart the SuperContainer Server and SuperContainer will read the value from the web.xml file, rather than from what is entered into the registration page.

Uninstalling SuperContainer

When deployed in FileMaker Server's Web Publishing Engine: If you have installed SuperContainer to run in FMS WPE, you can re-run the or WindowsInstaller.exe file and click "Remove" to uninstall from the Web Publishing Engine.
When deployed on Tomcat: If you have installed SuperContainer to run in a standalone version of Tomcat, you can simply remove the SuperContainer folder from the webapps folder of in your Tomcat directory.
When deployed in standalone mode: If you have deployed SuperContainer to run in standalone-mode (i.e. SuperContainerServer.jar file), you can simply delete the .jar file.

NOTE: SuperContainer saves its preferences in a file on your computer (when running in standalone mode by double-clicking the .jar file). On a mac, this is located at /Library/Preferences/com.prosc.supercontainer.plist. Remove this file to remove any stored preferences.

Removing Registry Entries

Windows: Search the registry for all keys which include "supercontainer" and remove them. Mac: Look for a file /Library/Preferences/com.prosc.supercontainer and remove it.

Known Issues

Memory Leaks in SuperContainer?

There is a documented and filed bug with Mac OS X's Core Images X Library, which does leak memory. SuperContainer makes use of Mac OS X's Core Image library by default, but also can use Mac's QuickLook library for image rendering.

This is not SuperContainer specific and is related to the Core Image library.

The best approach is to enable QuickLook for SuperContainer, the instructions for this can be found on our SuperContainer Product Support wiki page. See Enabling QuickLook.

Container fields in Windows that use OLE

SC Companion plugin behaves incorrectly, b/c FileMaker stores only the preview of the file internally and only the preview ends up uploaded to SC Server when using the Companion plugin SCSetContainer function.

Workaround: use ExportFieldContents script step and export the file then use the filepath to the file when calling SCSetContainer function.

FileMaker crashes when closing a window with SC webviewer

This is confirmed bug in FileMaker:

Behavior: when closing a FileMaker window containing a layout that has multiple webviewers displaying a Java applet, FileMaker crashes. A crash log is produced on the Desktop.

This issue is not specific to SuperContainer, this is a problem with all Java applets.

Platforms exhibiting problem:

  • XP
  • Vista

Java versions exhibiting problem:

  • Java 1.6 (we've tested several different updates, and there is no fix for this in Java 1.6 yet)

There are five possible solutions

  1. Downgrade to Java 1.5 -
  2. Use Custom Menus in FileMaker Pro Advanced to close/navigate to different layouts. See Creating Custom Menus in FileMaker Pro Advanced.
  3. Use FM script to either switch to a different layout then close, or minimize the window and then close
  4. Use the style=noapplet parameter in the SC URL
  5. Un-check "Enable the next generation Java Plug-in" option in the Java Control Panel -> advanced -> Java Plug-in

Expired certificate in SuperContainer Java applet

New certificate was included in version 2.56

SuperContainer applet not responding to mouse events(on Mac)

This was a bug introduced by Apple Java update for Mac.

Workaround was included in release 2.52

Weird flickering of SuperContainer applet

was introduced in version 2.52, in leu of working around bug in Apple's update (see above)

Fix added to version 2.58

Black or Grey webviewer, when using SC with other 360Works plugins

This may be caused by an old 360Works plugin, all plugins that were release by 360Works prior to December, 2008 can cause this issue.

Fixed in current version(s) of 360Works plugin(s)

Black or Grey webviewer, without 360Works plugins installed

This can be caused by an outdate Java Runtime 1.1.4 released by Microsoft.

I believe that this JRE is shipped with some Microsoft product and is installed silently.

Please contact 360Works for troubleshooting help/directions and fixes.

SuperContainer and proxies

Proxies can cause issues for the SuperContainer applet.

Please contact 360Works with specific problems related to proxies.

Plugin Conflicts

We have found a few plugins which cause issues with Java in FileMaker. As SuperContainer is Java-based, a damaged java being launched within FileMaker will prevent SuperContainer's java applet from loading properly. SuperContainer can still be used in noapplet mode, but the older, damaged java instances launched by these plugins will prevent the applet from working properly.

Plugins with known issues:

• All AcmeTech products, including MondoMail, NetTools, CCauthorize, JavaCompanion, and JavaScript Interpreter
• PDMSQL by Professional Data Management

Issue with deleting files stored in SuperContainer

When SuperContainer server is set to store files on a network drive, in presumably a Windows network

And a webviewer on a layout where delete script is executed is pointing to the file using a file URL instead of using SuperContainer RawData URL, the delete will fail without much of a message, similarly the file could not be deleted via Windows explorer from another machine.


I keep getting an "ERROR" when I use the plugin functions

When an "ERROR" occurs, definitely make use of the provided plug-in function, SCLastError, which returns detailed information on what the error is referring to -- and often provides great clues on how to resolve the issue.

This function is invaluable and can save you from hours (or even days) of headache when trying to develop a FileMaker solution that makes use of plugin functions. By reading through our section on Error Reporting with SuperContainer Companion plug-in, you will find out how to check for errors on each plug-in function that is used.

With that said, more often than not, the "ERROR" usually will refer to the base URL not being set yet. See: SCSetBaseURL().

I downloaded the Demo... now what?!

We have several resources available that go into some detail on how to to get started with SuperContainer -- most notably our documentation and the SuperContainerExample.fp7 file that comes with the downloaded content. The documentation outlines several steps on how to get started with SuperContainer, deploying an instance of SuperContainer on your machine, uploading files, and general use of the plugin .

In addition to our standard documentation for the plug-in, we also have a Product Support wiki page for SuperContainer that delves a bit deeper into the product, offering solutions and answers to common questions, usage tips, and troubleshooting help. I recommend that as a Go-To source for information and as a first line of defense when questions arise.

The SuperContainer forum on FMForums is also an ideal source of information and contains several threads of valuable information pertaining to the product.

If by chance, you would prefer to kick back and relax and let the makers of SuperContainer help to integrate its storage functionality into your solution, that's a perfectly viable option as well! We offer custom development work and can help integrate SC for you at our hourly rate of $165/hr. If this is something you think you would be interested in, please do not hesitate to contact us.

We are also available for any general support questions you may have about SuperContainer, or any of our plugins, so feel free to send an e-mail or give us a call if things start to get sticky.

SuperContainer Documentation:
Companion Plugin Documentation:
SC Product Support Page:
SC FMForums Page:

How do I know how SuperContainer is deployed?

To check if you are running multiple instances of SuperContainer, you can simply open/launch your favorite browser -- whether Safari or Internet Explorer and type the following into the address bar: (if connecting remotely)
http://localhost/SuperContainer (if running from the server machine)

If you type the above in and get a page that displays the version of SuperContainer, this means that you have deployed SuperContainer via the WPE of FMS. If you get a 404 error or File Not Found exception, this means you are not running SC via the WPE. Next, try putting the following into your web browser's address bar: (if connecting remotely)
http://localhost:8020/SuperContainer (if running from the server machine)

When specifying the "8020" port number, this indicates that you are running SuperContainer in "standalone-mode". If you receive a page that displays the version of SuperContainer, this means that you have deployed SC in standalone-mode (i.e. You have double-clicked the SuperContainerServer.jar file).

Double Scroll Bars on Web Viewer

There have been some instances when double scroll bars have been displayed when viewing an image within a SuperContainer web viewer. If this is the case, it may be that the window size has been exploded/increased and is being viewed at a value greater than 100%. This has been known to force scroll bars to display even with the "style=noscroll" set as a URL parameter. Ensure that the window is being displayed at 100%(max) initially. If the size of the window needs to be edited after the preview is generated to a value greater than 100%, this is possible to do -- if done after the web viewer has loaded.

PC Users are getting a Security Warning when Uploading

If your users are getting an error similar to:

"Warning - Security" "Java has discovered application components that could indicate a security problem." "Name: SuperContainer applet"

In the past, upgrading the Java JRE has fixed this issue. If you are running an older version of Java, try updating to the latest and see if this resolves the issue.

Not able to upload large files, SC deployed with FMS

IIS 7 has a default upload size configured at 30MB. This can be solved by adding the following code to the sites web.config file

                <requestLimits maxAllowedContentLength="2000000000"/>

Image files are not resizing

In it's normal configuration, SuperContainer can generate thumbnail images of JPEGs, PNGs, GIF files, and most TIFF files. It will not generate thumbnails for PDF files, CMYK JPEG or TIFF files, RAW files, or Photoshop files. If you are running the SuperContainer Server on OS X, you can enable OS X Core Image processing to resize more file types. See the 'Enabling OS X Core Image resizing' section above for instructions on doing this.

File looks like it uploaded but is not visible when I revisit the file/record

The files are actually not being uploaded to the SuperContainer server at all! With the advent of the Apple bug and the disabling of the Drag-and-Drop feature, which hinged on the use of Java applets, users have been dragging files/folders to the SuperContainer web viewer (this does not actually upload the file to SuperContainer but instead only stores a temporary reference to the location of that file).

In order for the file to be uploaded to the server, the user would need to click the button labeled "Upload File" after choosing/dragging the file to the Web Viewer.

By default, the web viewer has a "Choose File" button and an "Upload File" button... I would suggest that you ensure that they are first selecting the file with the Choose File button then, clicking the "Upload file" button to actually send the file to the server.

NOTE: It is important to note that we have (fairly recently) released a newer version of SuperContainer (version 2.852), which restores the Drag-and-Drop functionality without using Java applets. By upgrading to the latest version, you should be able to successfully drag and drop files to the Web viewer without need of using the "Choose File" and "Upload File" buttons at all.

Seeing the same document for all records

If you're having a problem with all of your records pointing to the same SuperContainer file, and you see that replacing it in one record replaces it in all other records, it's because your URL is not unique for each record. Include the primary key, or some other unique value, into the Web Viewer URL for each record, and then each record will be associated with its own separate file

How to handle "ERROR" response from plugin

If you try to call a plugin function, and you get a result of "ERROR", then call the SCGetLastError function to get a text description of what happened. It is always a good idea to have your scripts check the result of all plugin calls to see if an error occurred.

List all locations of log files

When troubleshooting a problem that you're having, we may ask you to send us a copy of your log files. There are several different log files for the different components of SuperContainer, and they are located in different places depending on whether you are running on Windows or Mac.

  • 360PluginBridge
    • Macintosh: /Users/yourUserName/Library/Logs/360PluginBridge.log
    • Windows: C:\Documents and Settings\All Users\Shared Documents\360PluginBridge.txt
  • SuperContainer Server log:
    • Macintosh: /Users/Shared/SuperContainer/SuperContainer.log
    • Windows: C:\Documents and Settings\SuperContainer\SuperContainer.log
  • SuperContainer companion plugin log:
    • Macintosh: /Users/yourUserName/Library/Logs/360Works FM Pro/360Plugin.log
    • Windows: C:\Documents and Settings\All Users\Shared Documents\360Works FM Pro\360Plugin.log

Providing the correct value to SCSetBaseURL

When calling SCSetBaseURL, you should include the portion of the URL up to and including the 'Files' portion, ie: SCSetBaseURL("http://yourServer:portNumber/SuperContainer/Files")

When calling other plugin functions, just pass in the portion of the URL that comes after the 'Files' portion, ie: SCGetContainer("Images/41")

Problems installing Tomcat

Some customers have reported seeing this error message when trying to start Tomcat, after downloading and installing it as a Windows Service:

The Apache Tomcat service terminated with service-specific error 0 (0x0)

This is not directly a SuperContainer problem, it is a problem with Tomcat. This can be caused by having Java 6 installed, instead of Java 5, if you are using Tomcat 5.5. Try downloading and installing Java 5 from to see if that fixes the problem.

Uploading package files

SuperContainer 2: supports upload of package files.

SuperContainer 1: Some OS X files, such as rtfd documents, are not really files, they are folders which are presented as a single file icon by OS X. These files cannot be uploaded through a web browser unless they are first compressed, such as a into a .zip or .sit file.

Thumbnails Are NOT Generating

If you've customized the path were SuperContainer saves files, and lets assume that you're saving to a folder at the top level of an external drive. Ex. save path /Volumes/External Drive/SuperContainer/ And you've only given write privileges to the SuperContainer directory you may experience problems with preview generation. The reason is that SuperContainer save the previews in the "thumbnails" directory at the same level as the directory where SuperContainer is writing the actual files. And if SuperContainer does not have write permissions it will fail in creating the "thumbnails" folder, thus failing to generate a preview. There are two solutions, first give write permissions to SuperContainer so that the following structure is possible: /Volumes/External Drive/SuperContainer/ /Volumes/External Drive/thumbnails/ Second solution is to point SuperContainer to the sub folder of the custom directory, like so: point SuperContainer to /Volumes/External Drive/SuperContainer/Files for example, so that the "thumbnails" folder is created like so: /Volumes/External Drive/SuperContainer/thumbnails.

Out of Memory

When resizing large images, SuperContainer may run out of memory. If you're running the SuperContainerServer.jar, you can launch it from the terminal with additional arguments which increase the maximum memory used by SuperContainer:

cd /path/toSuperContainer
java -Xmx600m -jar SuperContainerServer.jar

If you're running SuperContainer in Tomcat, add this line to the top of /Library/apache-tomcat-5.5.23/bin/, right below the #!/bin/sh


Same preview image after deleting a file and uploading new file

change Java Temporary Internet Files setting to NOT keep temporary files on the machine.

Standalone Mode on OS X Crashing

Newer versions of OS X use Java version 6 by default. Due to 64-bit issues, SuperContainer CoreImage support does not work correctly in Java 6. The workaround is to launch SuperContainerServer.jar using Java 5 instead. Use the following command to launch SuperContainer in Java 5 (substituting the correct path in the first step):

cd /path/to/SuperContainer
/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Commands/java -jar SuperContainerServer.jar

Registration is gone after restart

There is a possibility of a permissions problem with the registration information that is written to Java Preferences Mac: remove /Library/Preferences/com.prosc.supercontainer.plist file and re-register Windows: remove the registration keys from HKEY_LOCAL_MACHINE/SOFTWARE/JavaSoft/Prefs/com/prosc/supercontainer/model

An ampersand (&) or other special characters in the "Registered To" field can cause trouble with registration. To fix this, you must hard-code the registration information into the web.xml file. The ampersand must be coded as "&" (without quotes) instead of just an ampersand.

NAS Storage permissions problems

Use UNC notation and refer to server by IP address.

Error 500 in browser

Incorrect permissions is the likeliest cause of this error.

If using FMS deployment set the permissions to owner: fmserver rw group: fmsadmin rw If using standalone deployment, set read/write permission for the currently logged in user. If using Tomcat deployment, set read write for the user used to run tomcat.

Command line example for fixing permissions for FMS deployment: cd /Users/Shared/ chown -R fmserver:fmsadmin SuperContainer/ chmod -R 775 SuperContainer/

FileMaker crashing, Java issues

This from Kirk Bowman's email:

  1. I had a Java install that was not listed under Add/Remove Programs. I was able to remove it with this tool which I found on the Java site.

<;en-us;290301> <>

  1. I had a second Java Install which was from a trial copy of Crystal Reports. This is the install Jesse noticed in the logs I sent. I removed it manually.

Once they were removed, I installed JRE 6 Update 7 (for FMS9 compatibility) and the crashes have stopped on Windows with the SuperContainer applet.

SuperContainerServer.jar crashes

This crash may happen when 64 bit Java is used, since the core image C libs are compiled for 32 bit they won't work with 64 bit Java, the solution is to use 32 bit Java.

Dude, where are my files?!

On a Mac, if you configure SuperContainer to store images in a mounted volume, and one day it mysteriously stops seeing all the files it had previously created, but otherwise seems to be working normal, there's a good chance that someone tried to operate it while the volume was not mounted.

What SC does if you give it a path that doesn't exist, is it makes that path for you. This is a useful feature in most cases, but if the volume you are targeting is not mounted (on a Mac) SC will make a directory with the same name as the volume in /Volumes. Then next time the volume actually is mounted, the sym link in /Volumes gets a 1 appended to it. Fortunately this is exceedingly simple to fix.

Mount the volume, copy any files that were uploaded into the imposter folder to the proper location in the volume, unmount the volume, delete the folder and remount the volume. Done.

Jeremiah Small

Web publishing

Using IFRAME with PHP / XSLT

To include SuperContainer in your Custom Web Publishing site, just use a FRAME or an IFRAME with the same URL that you would use for your FileMaker Web Viewer.


Security concepts in SuperContainer

There are several options available to protect the contents of SuperContainer. Here are some possibilities:

  • Use the built-in username and password feature in SuperContainer: This will require users to enter a username and password before they can access the contents of SuperContainer. The advantage of this approach is that it is very easy to configure. The disadvantage is that if a user can access one item, they can also access any other item that they know the URL for. Another disadvantage is that all users share the same username and password.
  • Use the username and password feature in Tomcat: Configuring this is beyond the scope of this document (see for more information), but it basically works the same as the first option, with the addition of being able to configure separate usernames and passwords for each user.
  • Random URLs: This is probably the best approach to security, although it requires a little bit more programming work. Remember that nobody can access any document in SuperContainer unless they know the URL. By having each record include some random, hard-to-guess value, you can include that into the URL. Now each record can only be accessed if you, the FileMaker developer, choose to reveal the correct URL to them. As an example, change these URLs:

To these:


Now, malicious users cannot access unauthorized resources by simply incrementing the record ID.

Remember that you can combine these approaches as well - for example, using the built-in SuperContainer password with the random URL technique. Also see below for tips on SSL encryption.

Embedding username and password in SuperContainer URL

If you've specified a username and password that are required to access SuperContainer, you can include them in your Web Viewer URL like this:


Note that this behavior may not work in new versions of Microsoft Internet Explorer. See [LN;834489 this article] for more information. If you are having trouble with IE, you can:

  • Enter the username and password (users should only need to do this once per session)
  • Tweak the registry as per the article mentioned above
  • Switch to a different browser

Security issue with loading plugin in IWP

The demo file that comes with SuperContainer disables many of the plugin functions when they are being accessed through Instant Web Publishing. For an explanation, read the Security issues with Web Publishing article.

Using Apache's or IIS' SSL or Authentication settings

redirecting SuperContainer request from Apache or IIS

Redirecting SuperContainer request from Apache or IIS

redirecting SuperContainer request from Apache or IIS

Usage tips

Is opening the file to view it different with the noapplet parameter?

Yes, when not using the Java applet, SuperContainer will open files through the default web browser. For Mac OS X, this is Safari. For Windows, it is Internet Explorer. Each browser operates slightly different with various file types. Some browsers are able to render certain files (PDFs for example) like Safari, while others are unable to by default, like Internet Explorer and Firefox and instead download the file to the user's temporary or "Downloads" directory.

As a workaround you could use FileMaker's "Open URL[]" script step to open the file in the native application (ex., Adobe Acrobat for PDFs). An example of this is offered in our documentation for SCDownload() and attach this to a button on your layout. (See: "Opening a file in it's native program without Java Applets" below)

SuperContainer Security and Web Hosting

This is an issue and question that surfaces consistently. While operating under a web interface, it can be extremely difficult for someone to be able to access the file(s) directly, especially if those files are placed outside of the website's root file directory. Unless there is FTP access enabled, then only if the setup is sloppily done with no real security.

One good piece of advice about security when using SuperContainer and the web -- since the S.C. interface uses a 'web address' to pull the file and display it on the web browser -- DO NOT use sequential numbers to identify your files. The reason for this is that if someone was paying even the slightest attention, they would notice that the web address will display the ID of the file, like this -

Nothing is stopping them from manually typing in the address bar 

and so on to view documents/pictures you didn't intend for them to see. Use a highly unique identifier instead, like a UUID. It'll will increase the size of your web address/URL, but this also makes it near impossible for someone to "guess" an address.

Opening a file in it's native program without Java Applets

You would want to use the SCDownload() function in conjunction with the Open URL script step. The SCDownload will grab the file from the SuperContainer server and place it on the user's local machine. Then the OpenURL script step will open the local document in whatever program it would natively open in:

Open URL [SCDownload("Photos/12345")]

As seen above, the only thing needed in the SCDownload() function -- as with most SuperContainer plug-in functions -- is the folderPath (everything after the "/Files" piece) that points to the file on the server. Also as seen above, is that there is no explicit file name that is passed in (as it should be). So, by following the above, you should be able to get your solution to work as expected.

Link to SC Companion plug-in function (SCDownload()):

Question about naming strategies. Address the FAQ of why everything is stored in folders

FIX! Fill this in

Editing documents and using the plugin to re-upload them

FIX! Fill this in

Single record linking to multiple web viewers (ie. multiple URL's for a single record)

For the purposes of this example assume that we have a contact record that has to files attached to it, one file is the picture of the contact and the other file is contact biography Word file.

In order to have both files linked to the same record they both need to have some common piece of information, such as a record ID. As well, they both need a differentiating attribute, file type is a good candidate.

Example URLs: http://serverAddress:portNumber/SuperContainer/Files/recordID/FileType or

Using SuperContainer with portals

Here is a link to a sample FileMaker database file that uses SuperContainer with portals, container fields, and integrates multiple files/documents in a related record:

Using RawData URL to include images on public web site with an IMG tag.

FIX! Fill this in

Viewing multiple page PDFs within the web viewer

There are two ways to accomplish that in SuperContainer.


This requires that SuperContainer is running in 'standalone' mode on Mac. In this mode SuperContainer will automatically render the first page of the PDF. To get a preview of another page just use the page parameter in your URL. EX: http://localhost:8020/SuperContainer/Files/multi/page/PDF?page=1 http://localhost:8020/SuperContainer/Files/multi/page/PDF?page=4


This method requires that the system browser on user's machine is able to render PDF files. On Mac this is built in functionality, on Windows this can be accomplished by installing Adobe Acrobat plugin for IE or the equivalent. To load the PDF file in the webviewer use the following URL: http://localhost:8020/SuperContainer/RawData/multi/page/PDF

Using the context RawData tells SuperContainer to return the actual file stored instead of displaying a Java applet or HTML form to present the file. And if the browser is able to render the PDF then it will be available to the user right in the webviewer. Note that this method loads the complete PDF into the webviewer where the first method load just preview of a single page.

Industry-specific tips

Customizing the appearance of SuperContainer

FIX! Fill this in

Getting the file name of a SuperContainer file

Easy-peazy with the SuperContainer Companion plug-in. Take a look at the following example:

GetValue( SCGetInfo( folderPath ) ; 1 ) 

Where folderPath is the path to the file that is located on the SuperContainer server. If your web viewer URL is:

"http://servername:8020/SuperContainer/Files/Employee/Document/" & Document::ID

your folderPath would be: "Employee/Document" & Document::ID

This uses the GetValue() function and grabs the first line from the SCGetInfo() return-separated list. The first line (1), being the file name.

Using image transparency with SuperContainer

To use image transparency with SuperContainer, such as with a .png file, you must add "?style=noapplet" to the end of your supercontainer URL. Using this mode, you will not have drag and drop capabilities, so if you need this, you can have one web viewer on one layout without this parameter for dragging and dropping, and then the other web viewer on the layout that needs transparency. Consider that SuperContainer will not automatically detect width and height in this mode, and so you will also need to add "width=x&height=y".

Example: http://yourServer/SuperContainer/Files/path/to/files?style=applet&width=250&height=275

Storing the filename of an uploaded file in a FileMaker field

If you want to store the name of an uploaded file into a FileMaker field, first ask yourself whether it's really necessary. The way that SuperContainer is designed, FileMaker does not need to know the filename in order for the user to upload, download, view, print, or delete the associated document. However, FileMaker does need the filename in order to do searches on it.

If you decide that you need to store the filename in a field, there are two approaches, which both involve the optional SuperContainer Companion Plugin.

  • Option 1: Do not use the Web Viewer to upload files - instead use the SCChooseFile plugin function to get the path of the requested file. Then you can extract the name of the selected file into a FileMaker field, and use SCSetContainer to upload the document to SuperContainer. This option is very reliable, but will not work with the Web Publishing Engine (because the SCChooseFile function does not work on the web).
  • Option 2: Use the Web Viewer to upload the file, and then have a 'save' or 'continue' button that the user clicks after completing the upload. This can then use the SCGetInfo plugin function to get the name of the file and store it into a FileMaker field. This option is the one to choose if you need this to work with the Web Publishing Engine.

Preview TIFF images

Run SuperContainer on a Mac in standalone mode, by executing SuperContainerServer.jar file

Using SCScanDirectory()

Set Variable [ $setBaseURL ; SCSetBaseURL() ]

Set Variable [ $files ; SCScanDirectory( pathToDir ) ]

Set Variable [ $counter ; 1 ]
Set Variable [ $upload ; SCSetContainer( folderPath ; MiddleValues ( $files ; $counter ; 1 ) ) ]
if [ $upload = "ERROR" ]
	Show Custom Dialog [ "EROR" ; SCLastError ]
End If
Set Variable [ $counter ; $counter + 1 ]
Exit Loop If [ $counter = ValueCount ( $files ) ]
End Loop

Why can't SuperContainer store multiple files in a single directory?

One of the original design goals of SuperContainer was that it would work without requiring any plugins. This led to a series of decisions:

  • FileMaker is not capable, without plugins, of knowing the name of a file on the hard drive.
  • Therefore, it is logically impossible to embed the name of the file into a Web Viewer using only features built into FileMaker.
  • To solve this problem, we made it so that instead of representing the file name, the URL would just represent the folder that the file is stored in. This can be picked by the developer without regard to the actual name of the file.
  • Since this folder reference needs to unambiguously identify a particular file, it follows that a 1 folder must equal 1 file. If you reference a folder in SuperContainer that contains more than 1 file, it will just retrieve the first file it finds, ignoring any others in the same folder.

Some of our customers do know the names of the files that they are storing, and it seems natural to them to store many files in a single folder. In this case, we make the following recommendations:

  • Don't worry about it - just go ahead and use the file name in the URL. This will result in the file being nested one level deeper than necessary, but it doesn't hurt anything. For example, let's say you have a file called 'MyFavoriteFlower.jpg'. If you set your URL to '/SuperContainer/Files/images/MyFavoriteFlower.jpg', then it will be stored with this path on the server: images/MyFavoriteFlower.jpg/MyFavoriteFlower.jpg. Other than being a little annoying to know about this is harmless.
  • Drop the filename from the URL - SuperContainer will still store it just fine on the server. So for the above example, let's use the record ID (let's pretend it's record #17) instead of the filename: '/SuperContainer/Files/images/17'. This will be stored on the server as images/17/MyFavoriteFlower.jpg. This is a better approach than the first option, because if you have another different file called MyFavoriteFlower with record #18, it will be stored in images/18/MyFavoriteFlower.jpg with no name conflicts.
  • Remember, in SuperContainer 2, you upload entire directory structures to SuperContainer, so if you have a folder on your desktop named 'CoolStuff' that contains 'MyFavoriteFlower.jpg', 'MyFavoriteTree.jpg', and 'MyFavoriteBug.jpg', you can upload that folder into a single folder in SuperContainer. If your URL is /SuperContainer/Files/19, it will be stored on the server as a single zipped file in 19/

Enabling QuickLook

OS X 10.6 Snow Leopard and 10.7 Lion Only /Library/Preferences/

It should contain this single line: quickLookEnabled true

Apache upload limit

Edit the "server.xml" file located in your Apache Tomcat Directory. Add/Edit the "maxPostSize" attribute in the "Connector" element to increase the size.

     <Connector port="8080" maxHttpHeaderSize="8192" 
               maxThreads="300" minSpareThreads="25" maxSpareThreads="75" 
               enableLookups="false" redirectPort="8443" acceptCount="1024" 
               connectionTimeout="20000" disableUploadTimeout="true" 
               maxPostSize="104857600" /> 

Here is a link with more detailed instructions:

IIS upload limit

iis config file: %windir%\system32\inetsrv\config\applicationhost.config

                <requestLimits maxAllowedContentLength="524288000"/>

Moving SuperContainer Contents to a New Location

I've deployed SuperContainer to one location, and now I need to move SuperContainer, along with all of the associated assets, somewhere else. What's the best way to do this?

  • Move the Files directory

If you have access to the SuperContainer "Files" directory, the easiest way to move assets is to simply move the SuperContainer/Files/ directory to your new SuperContainer location. Upon deploying and configuring SuperContainer at the new location, SuperContainer will create a Files directory at the base URL you specify. Replacing this Files directory with the existing directory will maintain all of the assets and relationships from the current deployment.

  • Use the Companion Plugin

After setting the base URL at the new location, using SCGetContainer to retrieve the SuperContainer asset from the old location. Then use SCSetContainer to upload the asset to the new deployment location. You'll likely want to embed this in a looping script that will iterate through all of the SuperContainer assets. You can view a video about this process here.

Personal tools

Plug-in Products
Other Products