Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About GouldyFTW

  • Rank

Profile Information

  • Gender
    Not Telling
  1. Hi, I'm using the RemoteScripter Demo and the plugin example (FileMaker Pro Advanced 11 / Mac OS 10.6.8 / Firewall off for good measure!). The "IWP_Generate PDF" script appears to be working properly as it produces the PDF and (optionally) emails a copy to myself when run from inside FileMaker. The plugin appears to be working correctly as when I navigate to http://localhost:7244 the pdf is successfully created an emailed to the address I inputed in FileMaker. However when I attempt to generate the PDF using IWP, nothing happens and an error message is displayed at the
  2. Thanks for the reply. I think we've got the go ahead from the client today so I'll get that demo going ASAP.
  3. I haven't actually done this myself, so it's an educated guess! I've had a look at the documentation and found this command (which you're already using in the script above): RemoteScripterTrigger ( remoteAddress; portNumber {; parameterText ; timeout } ) You could pass the ID of the cover page to the remove script using the parameterText and then perform a find for the cover on the remote machine.
  4. Hi, We have built a solution for a client that tracks expenses within their business. They have now requested we extend the solution so that we can easily export the expenses as a list of transactions and import them into Quickbooks as this will save them a significant amount of time. We expected this to be a relatively simple case of exporting CSV/Excel from FileMaker and importing a each record/row as an individual transaction into quickbooks. Turns out this is not the case! Quickbooks will only import *.iif files - which I've had a look at and it doesn't look like it's going to
  5. Giant managed to answer the phone this morning! However they failed to do anything useful :/

  6. To summarise the problem, we have deployed part of our solution in IWP using HTTPS and have a problem downloading any file from a container field using Internet Explorer versions 7 & 8 (the other common browsers are fine). When clicking into a container, the file download appears to start and then you get an error stating that "data.file" cannot be found. I've been searching around the Internet looking for a solution to this problem - I've found a couple of threads, but found nothing useful. (you may find my posts at the bottom, before I decided to try and amalgamate the thread
  7. Sorry to drag up and incredibly old topic, but this is still causing me issues. I've checked that there are no scripts on my container fields and I get a blue 'hyperlink' of the filename in the container using IWP. The other top 4 most popular browsers on the planet download the file fine, but IE is causing problems. Unfortunately our customer's customers all seem to be using IE! Anybody had any luck with this? (P.S. Since this post I have found a few other threads, unfortunately none with any useful information, but have kind of amalgamated them here: http://fmforums.c
  8. Hi, My question is related to this - we have a system that generates some reports and saves them as PDF. We want to add access to these reports into a client area using IWP - RemoteScripter looks like the best option to achieve this. Presumably any report that can be generated using FileMaker can be achieved using RemoteScripter? And then at the end of the script I could have the remote machine either place the PDF in a container for the user to download or automatically email it to the user? Thanks, James.
  9. We've got a client using IWP for a client area on their system - this is deployed using HTTPS. Unfortunately this has caused problems downloading files from container fields with IE (as normal, all* other browsers work properly). Could somebody confirm that switching to SuperContainer would solve our issues? Thanks, James. * Well, the other browsers in the top 5!
  • Create New...

Important Information

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