Jump to content

IdealData

Members
  • Content Count

    2,667
  • Joined

  • Last visited

  • Days Won

    13

IdealData last won the day on September 3

IdealData had the most liked content!

Community Reputation

25 Excellent

About IdealData

  • Rank
    IdealData

Profile Information

  • Gender
    Not Telling
  • Location
    Leeds, UK.

FileMaker Experience

  • Skill Level
    Expert
  • FM Application
    14 Advanced

Platform Environment

  • OS Platform
    Mac
  • OS Version
    Yosemite

Recent Profile Visitors

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

  1. 49 files is obviously not a simple solution - determine if you really need to consolidate first. I've been running a 30 file solution for 20 years and have considered the consolidation route also. Originally I had nearly 40 files to deal with but I did consolidate some of them because they were merely "utility" files. I even created a new file to hold all the "contacts" from 5 other files simply from an interface perspective only (it makes sense in this instance). One of the benefits of a multi-file solution is that you can develop in different files at a time and deploy them individually. Possibly important if you have more than one developer! Some years ago I had a chat with a very experienced developer that retails a significant application; he said it nearly killed him and actually migrated a 30 file solution in 2 consolidations because he had to maintain a deliverable product. Break the problem down to smaller chunks that you might deliver as "modules" (like my contacts?) Factor in your migration path too - you need to get the data from your production system to the new version ultimately. The final product will likely be somewhat different to the end-user current experience so, once again, consider delivering in smaller units to take the pressure off yourself and ease the users into the new world.
  2. Devin You said WebDirect requires Safari or Chrome with JavaScript and popups enabled.
  3. Hi All Apparently FMI knows about this, and their advice is as follows The problem for me is I don't have an SSL certificate and am using the in-built FM certificate. I would have thought the in-built certificate would at least let me import from the hosted file, especially as I did this from the desktop of the server. The script doing the import has not changed for many years and still runs fine on pre-18 servers. Other than purchasing an SSL has anyone get a solution, without resorting to downloading the hosted files and running locally (I'm trying to avoid that step). Thanks
  4. I experienced something similar with FMS16. I was calling PSOS and after 30 or so runs the FMS script engine fell over and needed a restart. It never locked up the whole server though. Eventually I traced it down to using the Save As PDF during the PSOS, because when I removed the PDF generation then there was no failure.. Because I still needed the ability to run PSOS I built a server side "robot" to perform the scripting - thereby removing the PSOS from the whole scenario. The server side robot calls the script using standard method. As I say, it only appears to affect PSOS calls that involve a Save As PDF - everything else seems fine. Try using the command line tools to restart FMSE rather than reboot the server.
  5. Have a look at Custom Web Publishing - using XML. https://fmhelp.filemaker.com/docs/18/en/fms18_cwp_guide.pdf Nothing much changed since FMS16.
  6. If it did exist I suppose the script trigger would be OnWindowSelect The existing script triggers could be leveraged with the right techniques: OnLayoutSizeChange, OnModeEnter, OnModeExit, OnViewChange however all of these require some kind of action WITHIN the window. I don't think FM can determine that you have brought the window to the foreground.
  7. Look more carefully at the help. It is organised into 2 sets of options; one for Windows, one for Mac. It is a Mac specific feature.
  8. Hi Have a look at the "Install Plug-in File" script step. If you save the plug-in to a container you can use the above step to install the plug-in. Great thing about this is it works in all FM applications (except FM Go) and you don't have to worry about where to store the plug-in. HTH
  9. Hi First, get the Linux version of the plug-in. FM Go does not support plug-ins so you need to process your script on the server, e.g. PSOS. Merely installing the plug-in on FMCloud does not grant the plug-in features to FM Go. To install the plug-in on FMC create an FM file with a container that holds the plug-in and upload to FMC. Write a script to run on PSOS to use the "Install Plug-in" script step. That should install the plug-in on the server (because it ran server side!). You need to enable plug-ins on the server first, of course, on the Connectors tab. You will appreciate the beauty of running plug-ins server side when you realise you then don't need to install plug-ins for the client! HTH
  10. Hi Andy Wolf Bell I'm in Leeds. West Yorks - any good to you? 20+ years experience. More info at http://www.idealdata.co.uk
  11. However, each layout can be individually assigned I imagine that the "other" layouts are still using the "Standard Filemaker Menus" because that's what was assigned when they were created.
  12. I have a KIOSK mode application (please note NOT a runtime) that has been happily working since around FM11. The basis of the application is a door logging system that needs to pass the collected data on touch screen Windows tablets back to the server. The tablets also collect "user" records from the server so the user can be validated when they enter a PIN code on the tablet. It is designed to be network tolerant and will survive even when the network or WiFi have dropped out - hence it runs locally on the tablets. FM16 appears to have broken this, and I'm suspecting it to be a security issue. The KIOSK solution still runs fine in FM15 talking to a Server 15, and also runs ok using NATIVE FM16 to the same server. But the KIOSK solution in FM16 waits forever when it tries to open a file on the server, or possibly it is not displaying the "Security Alert" dialog. If I hit escape during the attempt to open the server file then the script advances (returns error code 0) but of course the file has not opened. I don't have SSL enabled on the server (don't want to!) and I'm not ready for Server 16 yet. Any one have similar issues or know a fix? Many thanks.
  13. I have tried all combinations of portal with/without scroll bars but cannot make scrolling happen when using finger swipes. It is possible to 'pin' down the scroll bar with a finger and then pull the scroll bar (same as a mouse) however cannot scroll when swiping up/down in the portal body. This has always worked in FM14 and FM15, but does not work in FM16. Any one else have the same experience, or fix? Thanks
  14. The PHP and XML access methods have independent extended privileges. Although you have authenticated your PHP session in your script this is not carried forward to the XML engine. Try setting the fmxml extended privilege to a "Guest" account. Support for the old http://username:password@address is almost non-existent. Did you also look at the php method getContainerData()? (NB. does not work for external storage))
  15. You might be better off knowing the UPLOAD speed of the client's internet connection. Whilst it's difficult to give exact numbers I wouldn't consider anything less than 10Mb/s useful except for remote-in methods. It's also not clear how many users are expected. Other factors include the ping response time and the number of router hops between client and server. At the very least test the experience first and get an opinion on performance.
×
×
  • Create New...

Important Information

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