Last time I developed for WD was in v14. I observed an important delta in available functionality compared to the ‘fat’ FMPA client.
Haven’t touched WD since, I’d like to collect the observations of peers who have worked on WD based layouts in FMS v17 or v18. What are the most important functional differences today?
Quick one, card windows not (yet) supported.
radio buttons, check-boxes differ in alignment
other things are browser-dependent, buttons with images (ie country flags for selecting language) will not show with internet explorer)
Do we trade OS dependencies for browser dependencies? 
not sure, what You mean.
We have a work in progress with webd. Many things are working really fine and we are happy when it comes to printing - under FM, that function will print to a printer, under webd, a new tab will appear with the pdf. Cool!
If You are under firefox, it will be different, not so cool for support…
We have to support 3 languages, one can choose via a button that shows the country-flag. This will not show under internet explorer…
looks fine under Safari…
1 Like
The move from local clients to web apps is primarily motivated by avoiding local installations and maintenance. The second reason is the independence from functional differences caused by the OS the client is running on. Actually we have to take care of what browser a user is using, if I got you right.
Yes, is another factor… we do have quite some users with firefox here - seems not to be a factor in the US (firefox is not supported - but with that many users, a webd solution is not possible without firefox here - so one needs to know what works how…)
Many differences are listed in the manual - but some others are tricky (like the radio buttons…)
- alignement: All one-liners vertical centered, labels and fields
- radio/check: Better have one option per field (not values a, b, c in one field but 3 fields with only one option, field ‘myField’ three times on the layout)
- text-blocks will not align as under FM, some developers created a block of text and placed some fields inside that block, will look terrible under webd
• fmp(XX)://$/-protocol is not supported, needs workaround with data api or php.
• data/text for webviewer is not supported by IE and Edge
• more objects need “forced” refreshs
2 Likes
URL encoding is browser-dependent, according to @samfmp’s post and @Otmar’s answer here:
https://the.fmsoup.org/t/why-this-sample-does-not-work-in-chrome/544
As others have noted, main things that lack in WedDirect that I can think of are:
- Card Windows (but coming in next version!)
- fmp:// URL support
- Checkboxes and Radio buttons render according to browser/OS default so styling not always suitable, but there are workarounds - replacing those elements with buttons that conditionally format etc.
- No ‘click-through’ to objects layered behind other ones, e.g. if you have a button layered behind fields it will not work.
- No text formatting within text fields objects, e.g. line spacing, bold, italic, size etc mostly ignored - uses text formatting specified for the field rather than sections of text within field. Text objects on layout do better, but line spacing not respected.
- Insert from Device script step not supported.
But a big benefit in some situations is much faster speed - when accessed from remote locations… Does not have as much latency as using FMPA and lots of the processing is done ‘on server’ so as long as server is good spec and solution is of good design then performance is very good. I recently worked on a file that was hosted in London but being accessed by users in Thailand, and the difference in performance between FMPA and WebDirect was night & day. They had been using FMPA for a couple of years and had just ‘got used’ to it being slow, so when I enabled and optimised it for WebDirect they were blown away.
…and of course it is amazing being able to instantly ‘publish’ your solution for others to use and not require them to install anything other than making sure they are using a supported browser.
These screenshots show script steps that are not supported in WebDirect (greyed out):
7 Likes
What hit me most is being tied to one window only
I make use of a second window for dialogs/wizzards quite often or use a new window of screen for calculation.
So this has to be solved if you depend on more than one window at a time
what is dead slow is showing related data in lists but it works at least
2 Likes
So do I. Not having a second/third window available would break workflows.
And the script step “copy” is partly supported in web-direct.
As a result, we have to use WebViewer or create a microservice to copy things to clipboard.
1 Like
I created a layout that looks like a second window overlaying and put a button « return ». 
2 Likes
did the same…
and that somehow reminded me of my FileMaker 5 - times 
Also beware of script triggers, some of these behave very poorly in WD.
3 Likes
In which way does the behaviour differ from FMPA triggered scripts?
@Torsten WebDirect triggers have limited awareness of what is going on in the layout and how the user interacts with it (mostly at the object / field level or for things that would ask to look at every keystroke). Awareness is improved if you have scripted commands that touch those objects (kind of what you have with FileMaker server scripts that interact with objects having triggers).
Layout triggers are more reliable.
See the notes for each trigger where support is said to be partial in the reference.
If support says no that means you will need to look at another way of doing what the trigger does in FMPro.
I don’t have a progression of support changes from 14 to 18, but as I look at the 18 help, support is fairly extensive.
You can also do a search for triggers in the WebDirect documentation. Like this.
4 Likes
I’ve used WD for some projects. It is really great, if you take in account what it does and what it doesn’t.
Things I miss the most:
- new window
- capturing special keys (like ALT)
The differences in layout between the different browsers and versions of browsers make testing time-consuming.
Each version it is getting better and if you combine it with server side scripts (I use the BaseElements plug-in) you can create very nice solutions.
3 Likes
skywillmott, I’d like to expand on your point number 4 a bit.
It should be noted that layering objects also fails in WD in the case of the “Hide Object When” feature. While a hidden object will not show up in WD, it also prevents you from clicking anything behind it. I occasionally have reason to stack two fields and show one or the other depending some condition. This works fine in FMP but not in WD.
4 Likes