When upgrading to FileMaker Server 19, look out for this gotcha with Card Windows on WebDirect

Card windows weren’t supported on WebDirect until FMS 19

The card window was first introduced in FileMaker 16. Since then, many of us have incorporated it into our design. At the time, it was supported on FileMaker Pro (FMP) but not on WebDirect.

If we try to open a card window on WebDirect with FileMaker Server (FMS) 16, 17, and 18, it will open the layout in full window size, similar to how other windows styles behave on WebDirect.

In FileMaker 19, by popular demand, card windows are supported on WebDirect. However, with this change comes an issue that might break our solutions, as happened to a client. In this article, I want to discuss this issue and offer a workaround.

Card windows on WebDirect (still) aren’t actual windows

On WebDirect, technically, we can only display one window per page. When we try to open a new window, WebDirect will treat it as a virtual window, meaning it will remember which layout our original window was on, then it will navigate to the layout with the new window.

When we close the new window, WebDirect will go back to the layout of our original window, but it’s really just one window. We can’t have two windows shown side by side, and they can’t be different sizes (they will be the size of our web browser window).

Now, some of you may be thinking, don’t card windows on WebDirect contradict everything I just said? Yes and no.

If you only look at the visual presentation of card windows on WebDirect, they appear to behave like a second window, but they are still not an actual window. They don’t behave independently from the main window behind it, and they just make a pop-up object look and behave like a card. Introducing the card window to WebDirect doesn’t change the fact that WebDirect runs in single-session.

Do card windows behave differently on WebDirect?

You may be thinking, “if it looks like a duck, swims like a duck, and quacks like a duck…”

Why do I care about whether it’s an actual window or not? Even though they look very similar, the card window on WebDirect behaves differently than the card window on FileMaker Pro or FileMaker Go.

One example would be if we have a card open in WebDirect, our main window in the background wouldn’t refresh until the card is closed, but that’s not the one that might break our solution.

Here’s the killer one: on FileMaker Pro, we can open up a card window then use the “New Window” script steps to open up other non-card windows. All of the new windows we open will float on top of our main and card windows. We can drag them around, resize them (if the corresponding options were turned on in our script steps), and close them.

However, we can’t do this on WebDirect. It results in error code 03, command is unavailable. Why would that be an issue?

Here’s the problem

This behavior by itself is not a big deal. If we know this constraint, we will design our solution around it. It becomes a problem if we also have the following habit:

Imagine we are on a layout doing data entry. For whatever reason, we’d like to create or modify records that we can’t access directly from our current layout, and we don’t want to leave our current layout, perhaps because we don’t want the screen to flash or because we don’t want to commit our record. What do we do?

Some of us will probably create a relationship to access the records we want to modify from our current layout.

Many of us have the habit of creating a script that will create a new window, go to the target layout, create or modify those records, and close the new window. Voilà. Data is modified, and the current layout/window is intact.

Do you see the problem here? With FM 19, we can’t open another window on top of a card window in WebDirect. The “New Window” script step at the beginning of our data modification script will fail, and the rest of our script might run under a completely wrong context. Imagine if there are a few delete records in there; now we have a problem.

But this is still not the worst-case scenario; as long as we don’t just run our solution on WebDirect without analyzing and testing it first, we won’t fall victim to this problem.

So where’s the gotcha?

Let’s take a step back. Earlier I mentioned that WebDirect did not support the card window option until FM 19. Trying to open a card in WebDirect before FM 19 will open the layout in full browser window size, just like opening a new window with other window options.

Card windows in FMS 18
Opening a card window on FMS 18 with WebDirect

This is certainly not ideal, but this also doesn’t break anything (as depicted in this article Card Windows work in WebDirect. I know some of us have designed layouts smartly to look nice both on a small card on FMP and on a full-size browser window on WebDirect. We make this compromise to reuse our layouts for both FMP and WebDirect, and it is a solid approach.

At that time, if we also happened to adopt the “New Window” approach mentioned above for updating data not available from our current context, guess what? We would be fine, because in FileMaker16, 17, and 18, we can open a new window from these not-supported card windows.

Now enter FileMaker 19. We are thrilled that we no longer have to live with the compromised look of these layouts; our solutions can look much better overnight.

Card windows in FMS 19
The same solution now opens on FMS 19 WebDirect

But uh-oh, these cards render differently; we can no longer open up a new window on top of them. Our scripts that used to work now run in the wrong context. Our excitement turns to horror in a second, watching our records get deleted in front of our eyes (which happened to one of my clients. Fortunately, we tried it in the QA environment instead of the production environment).

That is the gotcha.

Here’s the workaround

The most straightforward workaround I’ve found is to convert scripts that modify out-of-context data to run on PSOS. We can keep most of the script steps in them. We need to add a section that can receive and parse out the necessary script parameters and a section that can assemble and pass the script result. The rest are mostly fine. We can even keep the “New Window” script step, as it is supported on the server side.


Suppose you have a solution that’s used on both FMP and WebDirect, and you reuse many of those layouts for both FMP and WebDirect, including layouts created for card windows, and you have the habit of modifying out of context data using a new window. In that case, it’s very easy to fall victim to this problem.

If this doesn’t apply to you, great! Venture forward and enjoy the latest version of FileMaker.

If this does apply to you, I hope the workaround offered will be helpful to you. If you’d like to learn more from us, you can check out our training classes or our YouTube channel.

This technique is the result of our explorations. It may not be suitable for your needs. Each technique has its advantages and disadvantages and we invite you to do your own experiments and draw your own conclusions based on your situation.