1 2 Previous Next 15 Replies Latest reply on May 14, 2015 11:43 PM by wimclaessen

    Kill the Messenger


      There is an annoying message that appears for a split of a second on screen when my solution (only under WEBDIRECT) is asked to perform a script:

      "Wait for the script to be executed"


      Is there a way to prevent this message from being displayed?

      Would appreciate any advise.



        • 1. Re: Kill the Messenger

          Wild Guess: Turn Error Messages Off


          Could this be a browser thing? Try a different browser and see if you get the same result.


          My expertise in this matter is summed up in the first two words. 

          • 2. Re: Kill the Messenger

            It is cleary a message from Filemaker  server. It's the same with Chrome as with Safari. I would expect it to be caused by the WAN delays, although i have a quite fast network connection.

            • 3. Re: Kill the Messenger

              Perhaps the server is not fast enough for WebDirect?

              • 4. Re: Kill the Messenger

                Yeah, not a browser thing, just a default message the client receives when you perform a client-side script.


                Three things come to mind if you want to get rid of it, since it's a default you can't just turn it on or off.


                1) Make your script run faster, seemingly you probably already did this though, but fast scripts execute before the message pop routine runs.


                2) Use "Perform script on server: no wait" whenever possible, as performing a script server-side will not show the dialog, but waiting for a script to perform server side as a child of a client-side script will pop the dialog.


                3) Hack your CSS to add display:none; to the message CSS classes. I outlined the technique needed to do this last year: DevCon WebDirect Series 2 of 4: Printer-friendly CSS | MainSpring

                Completely at your own risk and expect hours of trial and error. Also it applies server-wide in case you have multiple WD files, so keep that in mind.

                • 5. Re: Kill the Messenger
                  Markus Schneider

                  I think this is the key..

                  - general performance of the machine/network


                  A second pothole could be found in the scripts: Is a script dealing with layoutchanges, loads a layout with a lot of 'heavy' fields (ie summary fields..), list layouts, is a script looping a couple of times, etc


                  THere is a 'performance guide' available from FileMaker that shows the problems

                  (I tried to find that guide - but I can't find it in english, all I got is the german version)

                  • 6. Re: Kill the Messenger

                    Yep! the bad baker blaming the bread kind of thing - often because the design is NOT optimized for Web Direct, the performance suffers, the client complains. And part of 'design' is having the proper server as Wim suggests!

                    • 7. Re: Kill the Messenger

                      This is the english documentation for webdirect:


                      Appendix A: "Design Considerations" covers what you should do to your file, but it doesn't really cover hardware.


                      The only place I've seen hardware considerations listed officially is on the tech specs page:

                      Technical Specifications for FileMaker Server 13 | FileMaker


                      Your "second pothole" is definitely valid, and I found in some cases makes a bigger difference than server hardware. Remember if you run a loop action without freeze window, the screen will redraw changes each time through the loop, and since FMS renders the changed layout in realtime, that will kill the server load and your client will suffer.


                      I got in the habit early on of developing an entirely separate interface (layouts, scripts, sometimes tables) for WebDirect, so I can completely control the UI behavior separate from the desktop experience.


                      If you want to get even more advanced in performance, you can generate and cache data for webdirect instead of using realtime calculated and summary fields. That is a huge boost in performance for systems with complex multi-field calc/sum functions.

                      • 8. Re: Kill the Messenger

                        Interesting replies. Something new to learn every day...


                        Keep in mind that if your user just sits and stares at a blank screen they may decide to just close the browser window and decide your web page...


                        No matter how good you code and even if there isn't that much or any at all, you are at the mercy of your internet connnection, if you are using one. Watch Hulu over WiFi in a cheap motel... 


                        Best practice is to show something interesting immediately before your code starts partying so the user will know you are working for them.


                        Avoid 5 Meg photographs since these will also take time over that cheap WiFi.


                        Text blobs load really quick so start them with something interesting. If you have 300 lines of start up code, go to layout 1 and run 50 lines then go to layout 2 and run 50 lines...etc.


                        Another amusing idea someone mentioned is to use the hide and peek feature of the Inspector beginning in 13 and insert a line in your code $$_Var=1 or 2 or 3 and use that to make hidden objects appear and dissappear. This way you can amuse your viewer and prevent the alert...

                        • 9. Re: Kill the Messenger

                          I always do a simple detection script and drop a user on a web direct dashboard.


                          themes that have background images are also not that great in WD.


                          You can run images through smush.it, and resize the images as well to the lowest size you need to optimize them.

                          • 10. Re: Kill the Messenger


                            • 11. Re: Kill the Messenger

                              I raised this with Vin Addala the FMI Product Manager for WebDirect a while ago.


                              He said that this message is essential as a means to lock the browser whilst the script(s) run. Apparently they can't do WD without it.


                              I think that with some encouragement they may use a better message or best still permit the developer to control what the message says?


                              What would you prefer?


                              Cheers, Nick

                              • 12. Re: Kill the Messenger

                                Actually, you can customize system messages in WD with a hack.


                                I covered this in my blog:


                                • 13. Re: Kill the Messenger

                                  Thanks Mike


                                  My general preference is to avoid ever using any hacks as there is the potential to create system instability in the future but, if what you suggest is merely changing a string then that sounds like a useful small modification.


                                  Have you used it successfully in production over a reasonable period without problem?


                                  Cheers, nick

                                  • 14. Re: Kill the Messenger

                                    It is, the most danger comes from the file just being overwritten, or accidentally removing the variables in the strings themselves. Everything’s outlined in the blog post. Good luck!

                                    1 2 Previous Next