Jump to content

Jerremy

Members
  • Content Count

    68
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Jerremy

  • Rank
    member
  1. Hi again David, Just want to see if what we are experiencing is the normal behavior or if something is not working right. When I go to the layout with 4 SCs (see SS above), they all get the "Connecting To SuperContainer Server..." message for 5-6 seconds. After they all load, if I click to the next record, this all happens again until all 4 load (and so on for each subsequent record). The load time is the same for a SC with or without an image. If I click back to a record that had already loaded, the SCs are already there - and do not have to reload. Is that what you mean by caching? Or, after the first record loads, each subsequent record should not have to reload the applet? I guess I'm asking if the applet just needs to load just once, then it's cached for all SCs on all records and layouts, or does it need to load for each instance of a SC, then it's cached only for that instance of the SC? Hope that makes sense. I've looked around at the settings in the Java Preferences.app. All the settings are there for caching. Under view cache files, sc_applet.jar is listed. Nothing changed when I played around with the settings. Thanks again for your help, Jerremy
  2. Hi again David, I'll try to do a little more investigating here now that I know it should cache and not reload like it is. It can't be a script as it happens when just clicking from one record to the next using the built in FM Toolbar. You mentioned default behavior of the browser - in our case, would a setting in Safari have any impact on the SCs on the layout. Not sure if the webviewers on the Mac tap into those settings or not. I'll take a look and see if I can find anything. Thanks, Jerremy
  3. Hi again David, Thanks again for the quick replies. You say that usually the comp caches the applet - is there something we can do to make it do so and not have to reload every time? All of our users are experiencing this - it's not just a few Macs that have the problem. We'd like to continue to use the drag and drop... and sounds like for whatever reason, it's not caching as it should. Thanks again, Jerremy
  4. Hi David, Thanks for the reply. Maybe that is the issue? It seems like the applet loads for each instance of SC on the layout, then again as you navigate to the next record and so on. Even if there is not a file in the SC, the four panels take 5-6 seconds to load until it displays the upload button. It takes another 5-6 seconds when you go to the next record, etc. Whereas, if I change the SCs on that same layout to no applet, I can flick through the records a second at a time and have the SCs load immediately, no waiting. Are you saying that after the applet is triggered to load on the first record, it should not have to 'reload' on subsequent records? Referencing the image I attached in the first post, This "Connecting to SuperContainer" happens each time you change a record and takes 5-6 seconds to load the SC. Thanks again, Jerremy
  5. Hi all, We are using the latest version of SuperContainer, 2.792 with Mac OS 10.6.8 with all Java updates installed. FM Server is v10. I've noticed a significant speed difference in SC when applying the noapplet style. If I click through records on a layout that has say 4 SCs on it, using the applet, all four areas will display a message "Connecting to SuperContainer Server...", then after 5 to 6 seconds, the images will finally load (see attached image). However, if I switch the SCs to noapplet, the images load instantaneously as I cycle through the records. Is the java applet that much slower, or is there something I can do to speed that up? There are many places I can change the SCs to the noapplet style because they are read-only areas, but users do like the drag and drop capability of the applet - I'd like to see how I can speed that up. As I mentioned, I've confirmed that the server has all the current system and java updates along with the latest SC. Anything I can do or check to see why the applet takes so long to load? Thanks for any help or ideas, Jerremy
  6. Yes, please (on the new plugin build). 2 more theaddeaths today... ...and I was surprised how many places in our system we were using the SCGetInfo to indicate that a SC attachment was present. I had to go through and remove them all - making our users grumpy. Here is a typical calc: Case(not IsEmpty(SCGetInfo( Job_Number & "/" & "Graphics" & "/" & Panel_Number & "/" & Random_SC_Link)); "YES"; "NO") Checks the path to see if the attachment is there. These all worked perfectly before we upgraded the plugin to the current version. Looking back at the changelog for SC, I believe the previous version we were using before 2.744 was 2.64 - so I'm not sure which version of the plugin introduced this behavior. Thanks, Jerremy
  7. David: Any updates? Users are still reporting threaddeath errors (although less than before - now using the test 2.745 plugin). I've also had to disable fields on layouts that use the SCGetInfo call because of the massive slowdown introduced in a recent plugin update. This is a key feature in our system as it indicates if a SuperContainer is present. Please - any progress? Thanks, Jerremy
  8. Hi David, Any updates on the threaddeath and/or SCGetInfo issues? Thanks, Jerremy
  9. Doh. I jinxed it. Just received a call from a user that just received the error. Confirmed that they have the 'new' version of the plugin. From the Console: Apr 30, 2010 1:54:57 PM com.prosc.fmkit.PluginBridge doFunction WARNING: No result in main thread AWT-AppKit for PluginFunction{name='SCGetInfo', functionID=-8372, minArgs=1, maxArgs=-1}. All plugin functions should always return a result!!! Apr 30, 2010 1:54:57 PM com.prosc.fmkit.PluginBridge doFunction WARNING: No result in main thread AWT-AppKit for PluginFunction{name='SCGetInfo', functionID=-8372, minArgs=1, maxArgs=-1}. All plugin functions should always return a result!!! Apr 30, 2010 1:54:57 PM com.prosc.fmkit.PluginBridge doFunction WARNING: No result in main thread AWT-AppKit for PluginFunction{name='SCGetInfo', functionID=-8372, minArgs=1, maxArgs=-1}. All plugin functions should always return a result!!! Apr 30, 2010 1:54:57 PM com.prosc.supercontainer.FileViewApplet$2 run SEVERE: Unexpected error occurred java.lang.ThreadDeath at java.lang.Thread.stop(Thread.java:716) at java.lang.ThreadGroup.stopOrSuspend(ThreadGroup.java:671) at java.lang.ThreadGroup.stop(ThreadGroup.java:584) at sun.awt.AppContext.dispose(AppContext.java:427) at sun.applet.AppletClassLoader.release(AppletClassLoader.java:807) at sun.plugin.security.PluginClassLoader.release(PluginClassLoader.java:438) at sun.applet.AppletPanel.release(AppletPanel.java:177) at sun.applet.AppletPanel.sendEvent(AppletPanel.java:275) at sun.plugin.AppletViewer.onPrivateClose(AppletViewer.java:877) at sun.plugin.AppletViewer$2.run(AppletViewer.java:826) at java.lang.Thread.run(Thread.java:613) The get info calls are for determining if the the record has an attachment, displayed via conditional formatting. So, although the number of error reports from users is down, it looks like the error still exists. Jerremy
  10. Hi all, The test version that David sent over appears to have fixed the java.lang.threaddeath error. It was installed on all machines on Tuesday morning, and there has not been a report of the error since. However, we are still experiencing an issue with SCGetInfo calls. Fields on layouts that use this calc SLOW use down to a crawl, making the layout beachball. This behavior was not present in previous versions of the the plugin. oilcan, I'd be interested to see what happens if you install the plugin and use the technique to create the error... Hopefully this fixes the issue. David, thanks for your help on this - but have you found anything that would lead to the slowness caused by the SCGetInfo? Thanks, Jerremy
  11. Hi again Dave, Sending some log data to you now. Thanks for your help. Jerremy
  12. Hi David, I will try to capture some console errors as soon as I can. Users are in 10.4.11 and 10.5.8 with all other OS updates applied. All users have the latest SC (2.744) and SM (3.33) plugins installed. Also of note with the latest SC: Users are reporting - and I have confirmed that any layout that has a field that calls the SCGetInfo() command will beachball FileMaker for 15 seconds before allowing the next input. For example, we have a layout that shows a list Work Orders for a job in a portal. There is a field that calls SCGetInfo() to see if there are files in the SuperContainer for that Work Order. This layout had no issues before we upgraded to the latest SC plugin (2.744). Now, the layout beachballs immediately. I had to remove the attachment indicator field from the layout - as it became unusable. ...Not sure if it's related - but it definitely coincides with the plugin update. I've emailed the staff asking to note the error time and call me over when the 'threaddeath' error occurs. I'll grab the log info and send it over to you as soon as I can. Thanks, Jerremy
  13. Hi all, Users are reporting an error in FileMaker that looks to be caused by SuperContainer. While on a layout that has a SuperContainer, a popup error message displays with: "java.lang.threaddeath". The user then cannot close this window and has to force quit FileMaker. We are running the latest SC, 2.744 on Mac OS 10.6.3 Server in standalone mode. All users that have experienced the error are running the latest version of Mac OS 10.4 or 10.5 will all secondary updates installed. All users also have the latest SuperContainer and ScriptMaster plugins installed. Also, one user reported the same error while using Safari to view an IWP page that has SuperContainers on the layout - so the error is not just limited to FileMaker. This is a new error that we have never experienced before, and we've been using SC for 2 years now. We did just recently update to the latest version of SC. Anyone else having this issue? Did a search of the forum and I did not see a post with this error listed. Thanks, Jerremy
  14. Hi Jesse, THANK YOU! This works. It is also noticeably faster when loading the images. Our design department will be VERY happy. Thanks for fixing this - SC is going to be a very useful tool in our FM system. Have a great holiday weekend. Jerremy
×
×
  • Create New...

Important Information

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