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.
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.
Perhaps the server is not fast enough for WebDirect?
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.
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)
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!
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:
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.
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...
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.
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?
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?
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!