Data Viewer won’t display script variables if opened after script start

The other day I was unit testing a FileMaker script that reassigned a bunch of field values in a set of records. I needed to pay close attention to the values being captured at each step, so I was using the debugger and the data viewer to keep an eye on things.

I tend to use a lot of SetVariable steps, to keep my code tidy and efficient. So in this particular case, I was primarily concerned with the values being stashed into a set of variables.

But when I looked for them in the data viewer’s Current pane, they often weren’t there at all. Sometimes this happens normally, when the value of your variable is null. Keep an eye out for that so it doesn’t catch you off guard. But in my case, I knew those values weren’t null — so where were those variables in my viewer? Every once in a while they’d show up as expected. Weird!

Finally I saw the pattern: if the data viewer was opened BEFORE the script started, all the variables showed up properly. But if I waited until a few steps into the script to open up that data viewer window, my script variables never showed. So keep that data viewer window open during your debugging, so you get the complete view of Current expressions. I had been closing the data viewer when I went to adjust my code, because it stays on top and tended to obscure my view.  Then I’d forget to reopen it until I was already running the test.

Once I figured out the behavior, I started resizing the data viewer window instead, shrinking it and moving it on top of my debugger window while I edited my script, to keep it always open but out of the way.

3 thoughts on “Data Viewer won’t display script variables if opened after script start”

  1. Switching tabs will fix the problem too. Click on “Watch” and then click on “Current” to force a refresh and see all the variables from the running scripts.

  2. Hi July –
    “The other day I was unit testing a FileMaker script that reassigned a bunch of field values…”

    I’m curious: can you share more about the approach you use for unit testing? I have one that I’m developing, but you’re the fist I’ve seen to refer to active unit testing for FileMaker (aside from the folks who say it’s impossible!).

    Thanks,
    Allen

  3. Hi Allen — I thought this post was so old everyone had stopped reading it! Unfortunately, I’m inclined to agree with the folks who say unit testing FileMaker is impossible, in the strictest sense of the term — but I do find that over the course of a project there do end up being small chunks of functionality that I test in isolation. In this case, we were changing one aspect of a complex process already in production, and so I was not doing a full-blown test of the functionality, but rather focusing very closely on a small set of field changes in specific. I thought of that as a unit test, but that’s a semantic liberty taken on my part. I’d be very interested to hear more about the unit testing approach you’re working on, to see how you’re addressing the difficulties of doing so for a FileMaker application.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top