Absolutely. Guilty as charged.

But with all due respect, testing is unreliable because it relies on a
'feature' that is undocumented, and therefore the behavior is
potentially volatile. It may work when you test it, but that's no
assurance that you can rely on it in general.

This would need to be tested on both Windows and OSX, in multiple
versions, and multiple versions of filemaker on each before it could
really be deemed safe. (And even multiple settings of different
versions... for example the window compositing engine of Vista's Aero
is entirely different than the one used for Vista classic)  And even
then there is no guarantee it will work in the next release of any of
the 3 products. -- who knows -- maybe the next version of FM Pro will
be fully multi-threaded and support using an unstored variable as a
clock.

That's not really unexpected. Filemaker's recalculation of unstored
calcs is complicated and undocumented, but we DO know that unstored
calcs are not real-time updated on the fly when the underlying data
changes (at least in current versions of FM). For example, its well
known you can't have an unstored calc set to Get(currenttime) and use
it as a clock. And if you put such a field on multiple layouts/windows
it will appear to be frozen at whatever time that layout / window was
last updated.

Right?

But by that same token, that doesn't mean I would advocate
deliberately using an unstored gettime calc for the *purpose* of
displaying when I last visited the window, because i can't rely on the
OS not needing to refresh that window for its own reasons, and
updating the time value in the process.

The same sort of logic applies here.

The way to make it fail would be to force Filemaker to re-evaluate the
non-selected window -- without selecting it. Any sort of active script
or manual direct manipulation of the window clearly won't do it.

An example of the sort of technique to mess it up would be to drag the
current window over top of the unselected window, and then move it off
again. The just-hidden-and-now-revealed window would need to be re-
displayed, but since it really and truly is -not- the selected window
and never was through the transition, its hard to say what FM would
do; according to the documentation it would evaluate to the value of
the currently selected window (ie the one you are dragging, not the
one that needs repainting.)

Of course, perversely, the above example won't likely actually work,
because the OS caches the hidden window contents for performance
reasons (precisely so it can display a revealed non-selected window
without potentially having to swap the parent application back into
memory just to ask it to redraw it), so when you move the top window
away the OS doesn't may or may not ask filemaker to repaint the
screen, with a preference on not.

So to make it -actually- screw up, we're talking about something
involving revealing the non-selected window after the OS has released
the cache... maybe after waking from sleep/hibernate... maybe after
doing enough 'other stuff' in a low memory system.

There may also be things we can do that force filemaker to request a
repaint of a non-selected window without selecting it. For example
adding a record to a table will cause other windows on that table to
automatically update the found count... that may or may not also
trigger a recompute of unstored calcs in current or future of versions
of filemaker.

Relying on the idiosyncracies of the timing of Filemaker's window
refresh and recalculation is asking for trouble. Its relatively easy
to force FM to recalculate and make things "current"... but it does
have lots of situations where it or the OS will decide to refresh
things... and relying on it "not to" is inherently risky.

I wouldn't be surprised if FM maintains a internal buffer between the
actual OS window name, and what FM uses.

e.g. I wonder if you were to use one of those utilties that lets you
rename the window(s) of a running program whether FM would even see
the new name or not?

That would be one issue. If it pushes the carriage returns out to the
actual window instead of or inaddition ot maintaining a buffer, it may
also mess with "task manager" programs, and other programs that query
the window names.

It suffers from one of the same issues as the latter. The value of the
unstored calc get(windowname) is defined as being the value of the
*currently selected* window. So if a non-selected window is somehow
refreshed/repainted without being made current, strange things could
happen.

best regards,
Dave