Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About ooparah

  • Rank

Profile Information

  • Gender
  • Location
    Roswell, GA

Contact Methods

  • Website URL
  • Skype

Recent Profile Visitors

3,648 profile views
  1. A couple of general troubleshooting questions (QuickFire-style): 1. Do you have any other plug-ins installed on either machine (more importantly, the problem machine)? 1b. If so, are all of these plug-ins up to date? 1c. Any plug-ins installed in your AutoUpdate folder? 2. What version of Java are you running on either machine? Looking forward to hearing back from you,
  2. Hey Tony, This can sometimes be the case with multiple installations of FileMaker server on a single machine (FMS11 & FMS12 for example). It seems as though if FIleMaker is not properly uninstalled there are some remnant pieces left behind in the Windows registry that toys around with SuperContainer's WindowsInstaller.exe file. My recommendation in these edge cases is to simply install SuperContainer using the manual installation instructions. Or, more simply, deploy SuperContainer using an alternate deployment method (i.e. standalone mode or via Tomcat ). I hope this helps,
  3. Hey Jeff, Take a look at our SuperContainer Product Support wiki page which discusses the black web viewers under the known issues section. More often than not this issue is one caused by an outdated version of Java and uninstalling and reinstalling Java usually remedies the problem. Also, if you want to avoid using Java applets, you could try appending the "noapplet" style to your web viewers. This should workaround the black box issue (assuming installing a newer/working version of Java is not possible). Regards,
  4. Two approaches to this: 1. Update to the latest version of Java by visiting Oracle. Or, you may need to: 2. Explicitly use the "noapplet" style in your web viewer to avoid the "Missing Plug-in" message. Hope this helps,
  5. For multi-machine deployments if you want to have SuperContainer run with FileMaker Server it does need to be deployed on the machine running the Web Publishing Engine. However, we offer three deployment options. 1. Run SC in standalone mode 2. Run SC through the FMS' Web Publishing Engine. 3. Run SC with Tomcat Our documentation goes into a bit more detail on the approaches for each. Regards,
  6. Gary, Yes, using User Agents or some derivative of this is one way to handle cross-platform applications. There are some better answers and solutions online that could answer this much better than I can though. Regards,
  7. Hey there, After reading through this post I noticed that several issues and snags that you've run into are a direct result of running an outdated version of SuperContainer -- as you alluded to in your first item. To avoid 2(a) and 2( b ), simply update your deployment of SuperContainer server to the latest version (2.864) and the Companion plugin (if in use). If you are still experiencing these issues after the fact. I will be more than happy to help you troubleshoot those issues as well. Good luck,
  8. Prob, Passing in RawData/ should be all that's necessary here, but after some initial testing locally it seems as though this is a small bug in SuperContainer. You can however workaround this by passing in both width and height URL parameters for the image. For example: RotateImage( "http:/[serverAddress]/SuperContainer/RawData/[AssetID]/PNG?width=550&height=230" ; 90; "" ) I hope this helps,
  9. Matty, Take a peek at using style URLs with SuperContainer. Also, depending on whether you're viewing the SC file using a Java applet or not will determine whether a "Delete" button is shown by default. Again, taking a look at SC styles should help with the Delete button issue you're running into. Regards,
  10. James, It looks like you'll probably need to use a standard FileMaker Container field to grab and store the PDF preview. Hopefully you're running SC in standalone mode on Mac OS X so that you can grab a preview of the PDF image using Core Images X library and save that to a container field using SCGetContainer() (with a width and page number specified). This should eliminate the Preview mode problem as well as the Acrobat Editor raining on your parade. Hopefully it works out for you. This is my best suggestion without sitting down with pen, paper, and a gallon of coffee. Re
  11. Michael-- You can place the downloaded SuperContainer folders virtually anywhere on the hard drive, so long as the files stay together and are not renamed. You can create a parent folder however, "Project X" for example, and place the SuperContainer directory within that folder. Hope this helps,
  12. This is the correct approach. How are you inputting your username and password in this .xml file. The resulting web.xml file should look similar to: where "user" has been passed as the username and "pass" is the expected password. With this web.xml file saved, the next time a user attempts to access any file or the registration page on your SuperContainer server, they will be prompted. For SC deployments in standalone, you would enter the same credentials by clicking on the "Options" button after launching the SuperContainerServer.jar file. Regards,
  13. Hey Ron, How are you displaying the images? In a Web Viewer? Container Field? What Windows OS do you have SuperContainer server deployed on? Are you running the latest version of both SC server and the Companion plug-in?
  14. All SuperContainer error codes are simply HTTP error codes regurgitated back to the client. A quick way to know what SuperContainer is complaining about is to use SCLastError for a more detailed description. Or, when it comes to error codes, doing a search for the error code usually sheds a bit more light. Did you make any updates to your environment that could cause this failing? Have you tried alternate browsers and tested against their results?
  15. Issue was that a full URL, along with a filename, was being passed into the SCSetContainer() function)... ex: SCSetContainer( "93.999.999:8020/SuperContainer/Files/Test/MyImage.jpg"; Table::ContainerField ); One way to fix it was to pass in the folderPath and the desired filename you wish to rename the file to as an additional parameter: SCSetContainer( "/Test"; Table::ContainerField ; "filename=MyImage.jpg" ); However, because the plug-in call was returning a "1" tosses this under the "bug" label. We will work on fixing this in a future release of the plug-in. Re
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.