Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


eswanborg last won the day on September 26 2011

eswanborg had the most liked content!

Community Reputation

1 Neutral

About eswanborg

  • Rank

Profile Information

  • Gender
    Not Telling

FileMaker Experience

  • Skill Level
  • FM Application
    16 Advanced

Platform Environment

  • OS Platform
  • OS Version
    High Sierra/Win 10

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Have an odd situation, just wondering if anyone else has ever seen this. We have a solution that's been in use for 10+ years now - so started I think as a v7 database. Our developers are now running v18 while most clients are v16 or v17. I made an adjustment to a script last week to an Import Records script step. It's all internal, just importing a record from one table to another. In v18 the mappings all look and behave correctly. However, for any clients on < v18 the mapping of the fields was totally messed up. Not off by just one field but all over the place. Same script from the same hosted file showed two very different field mappings in that script step. I went back in via v16 on my machine - fixed the mappings and now they're OK for all client versions. We've got hundreds of scripts in our solutions - never seen anything like this. Just wondering if it was a total fluke or if it's something we should be concerned about. Thanks
  2. After troubleshooting with Ryan offline - this was just a cache issue in Safari. Interestingly, Chrome had no problem with the URL. Firefox got stuck on TLS Handshake problems (much like Safari). But after clearing the Cache (via Developers menu in Safari) and removing all Website content (via Preferences) - it's back up and running as expected.
  3. FM clients. We have other solutions that are accessed via Webdirect - those are all OK. We're really only seeing this problem on High Sierra FM client users. And again, the scripted interactions all work - it just can't load the webviewer. It's not accessible - but let me see - I may be able to screen share with you if you think that would help.
  4. We're trying to track down a problem and wondering if anyone has seen anything like this: Setup: FMServer is Win2012, web server (multiple machine deployment) is MacOS (Supercontainer running here). Our High Sierra clients are able to interact with SC content if it's scripted but the actual webviewer does not display anything (we sometimes use it to preview PDF or images). Win10 clients are OK. Older MacOS clients are OK. Seems to be limited to High Sierra (and maybe Mojave but we don't have many of those). We've tried updating Java, switching to HTTPS - no luck. The only substantial change recently was that we did get valid certs for both servers and do have SSL connectivity now. Just not sure why only High Sierra clients are having trouble displaying the webviewer. It just sits on "Loading" and eventually times out. Any suggestions would be appreciated. Thank you
  5. Nevermind - appreciate the help. Discovered that some users still had a mix of plug-in versions installed. This issue is RESOLVED with SuperContainer v2.9510. Thanks so much! Phew!
  6. Hi all - back to this topic as it's still a problem for us. We abandoned the dialog box and just did a forced-save to the user's desktop with all files. We're still stuck on Windows machines though - they can download the first file but any additional attempts to download other files throw Java errors immediately. The only remedy is to quit FMP client and reopen. I went through some of the other troubleshooting steps - installing 32-bit Java (already there), creating the local/360Works/Plug-ins/jre folder and unzipping the contents of the support files, etc. Still no luck. What other suggestions do you have for me to get Windows machines to download more than one file per session? Thanks 360Plugins_FMPro.log
  7. Good thought - but I tried this: deleted all the plugins (we do use SuperContainer and ScriptMaster) and restarted FMPA. I opened the database in question without letting any of the startup or other scripts fire. Even then (with virtually nothing loaded) I get the same result.
  8. Yes, immediately - no steps executed. Just by calling it. And I wish it were a script parameter but it even happens from the Script Editor where there isn't a Script Param to pass in...
  9. First - thanks all - I really do appreciate the ideas. I've been developing in FMP since v5, about 22 years ago and spent 10s of thousands of hours in it. This is a first for me. While on the surface it feels like it's something getting set along the way, I do not believe it's anything in the database itself that is causing this issue - nothing in startup script, or custom function or even data viewer are setting the $var. With data viewer open (yes, we develop in FM Advanced) - prior to triggering the script in question I only have the $$vars that are set in startup script. As soon as the script in question is active - although no steps yet executed - the $var appears - again, zero steps actually completed, just open in Debugger waiting to step through. And the $var in question isn't even part of the script itself any longer either - yet it still shows in Data Viewer as a $var with a value being set... On top of it - I've checked multiple machines, user accounts, etc. and still, only my v16 install on my Mac displays this behavior. Same Mac with v14 is fine. My PC with v16 (also FMPA) is fine. Other user's machines, fine. Clearing out all my preferences cause Data Viewer to be reset (among other things), nothing. Stepping through scripts on all machines show nothing. It's truly odd. If it were in the database somehow I'd have to believe that I'd see this behavior on another machine or version of FMP somewhere. And by clearing all prefs (which clearly did happen) I'm intrigued by what file I'm missing somewhere on the system that could possibly be holding cached (or otherwise) data about this script and $var. And I know you'd like to see the script steps themselves, but I promise it's nothing special. Sets a handful of other variables (dates, etc.), checks a value of a couple of fields and depending on those values would eventually set the $hours variable. At this point I've removed that $hours altogether from the script - it's now $vacHours - but still, in only my v16 install, script debugger & data viewer show $hours being created immediately and the value is unable to be edited. I'll likely chalk this up to some odd quirk and move on. Again - in all my years of working in FMP I've never seen anything like this. I'd just love to figure out what it is to ensure it doesn't occur on any other client systems.
  10. Gotcha. No AS at all in this. It's a very basic script to gather vacation time tracking and process it. For some reason I can't paste the script code into this post. But it's really nothing other than setting some variables, doing a little math based on those variables and creating (or not) a new record. And again, this isn't so much for me about solving this script - I have lots of ways around that - it's more about why my machine seems to think that variable still exists and ensuring that goes away. Somewhere on my machine is cached data that is not getting flushed. It makes me wonder what other types of info might get "stuck" like this with other solutions. I do appreciate the help though! Thanks!
  11. I can - but the strange part is - I have completely removed the $hours from the script altogether - and still in Debugger that variable appears as being set. So while I can show you want the script looks like now - that variable doesn't even exist in the current iteration of the script. It's totally strange... Been working in FMP for about 20 years and never seen this one before.
  12. I have a situation that I've never seen before. Mac OS 10.13.3 and FM Advanced In a script, I had been setting a local variable called: $hours. As I was debugging part of the script I noticed that the $hours was being set as soon as the script was triggered - in Debugger not a single step was executed yet and somehow the $hours was set. I've tried everything I can think of and yet in that script $hours is still being set and the worst part is the value is not editable. Can't overwrite it with a script step, can't manually change it - nothing. I've deleted prefs, cache files, everything I can find that has filemaker in the the name in my User/Libaray folder. Restarted. Etc. It must be tied to v16 in my profile on my machine because this does not happen at all on v14 of the same machine nor on my PC. I'm just baffled as to what file on the computer is holding that information and how I can make it go away. Next step is to completely un-install v16 and start over there I guess. I've changed the script to use a totally different variable now to ensure the script executes properly, but would love to solve this mystery - I'm a little worried that if this were to happen on a client machine they would get bad data when executing scripts. Anyone see anything this strange before?
  13. Will do - just ran tests with a whole bunch of combinations of the plugins. Unfortunately, not getting different results. Will send logs from all tests. The FX application thread error (based on the latest round of tests) appears to be thrown by the latest SuperContainer plugin - not ScriptMaster. That only shows up with SC 2.9510. Anyway - logs and notes will be sent to your support address. Thanks
  14. Just circling back one more time hoping someone might help... I've now completely wiped my machine of all things Java and Filemaker and reinstalled from scratch. Running JRE 8 u161, FMAdvanced 14.0.6 and FMAdvanced 16.0.4 - all on Win10. Using 360Works Plugins: Supercontainer 2.93 and ScriptMaster 4.42 FM v14 has no problems. All SuperContainer functionality works as expected FM v16 can download/upload a single file. Successive attempts throw the java.lang.NullPointerException each time Using 360Works Plugins: Supercontainer 2.9510 and ScriptMaster 5.09 Both versions fail to interact with Supercontainer documents at all. They all throw error: Not on FX application thread; currentThread = PluginBridge worker -1 thread-1 We are supporting several databases for a large studio environment. I'd really love to get this sorted out. Anyone able to review?
  • Create New...

Important Information

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