Window Controller

Where it all happens and why

You already saw that the Size and Alignment tables contain only data. All the calculations happen in the System table, in the Window Controller field. If you open it, you'll see a huge auto-enter calculation that reads preferences, default or saved settings, passed parameters, then calculates intermediate values, such as available desktop size, and finally yields settings for top, left, width, height, zoom level and status toolbar state and stacks them together. Other global fields simply copy these values from the controller.

This is somewhat unusual, but necessary and practical behavior. Consider a situation when the user, say, clicks a button in a portal and you need to go to a related record in a new window. The table you're on and the portal are completely unrelated to the System table and tables that store window sizes, alignments and settings. You can set globals in System, but these globals are mere links to related records; to use the related data you need to somehow do all the calculations from the context of the System table. But you cannot just switch there to do this, because you have a portal row selected and will lose it if you do.

You can fetch all the related settings into global fields, but there's too much of them, there's three tables after all, and once the math is done, all these data are no longer necessary. You can also remember the portal context and then restore it somehow, but this is extra work. So it pays to go an extra mile and find the way to run the calculation from System without actually switching to it and without loading all the data into temporary fields. With these considerations a global field with an auto-enter formula seems to be quite a practical option.

It's a bit difficult to debug such a formula, but not that difficult; you can do most of the work in the Data Viewer.

What does Window Controller take into account

Window Controller knows and tries to handle the following:

• Under Windows FileMaker v7-9 doesn't see the status bar at the bottom of the screen. This is not the status area, it's just a strip across the bottom:

  

  It can be turned on or off, but there's no function to check its state and the Get( WindowDesktopHeight ) function doesn't see it. FileMaker v10 doesn't have this status bar anymore.

  Window Controller cannot see this either, so it guesses the bar is on. See the in-field comments.

• FileMaker v7-9 doesn't see toolbars. You can check if they're allowed or not, but cannot check whether they're actually on and what size they occupy. FileMaker v10 doesn't have toolbars anymore.

  Window Controller guesses the toolbars are on and occupy a single line at the top of the screen. See the in-field comments.

• Under Windows Get( WindowDesktopWidth ) and Get( WindowDesktopHeight ) report four pixel less in either dimension. (Of course, this will affect only windows that try to be as large as possible without getting maximized.) You can actually see these pixels; they seem to make some Windows-specific 3D effect. Window Controller knows about this and subtracts them from available desktop size.

• Starting with v10 FileMaker has a different status area. The old status area used to be at the left, took 69 px and when it was on, it shared space with the 3-pixel area that is displayed in list and table views. In v10 it became a status toolbar and went to the top. It consists of two bars, larger and smaller. Under Window their size is fixed. Under Mac OS X the larger bar can have different dimensions that may also vary per mode. Window Controller handles this automatically, except these per-mode variations.

• The new status toolbar also behaves differently. Under Windows toggling the toolbar doesn't change the total size of the window, but adds more space for the content. This behavior is probably not perfect, but similar to what it used to be so far. Under Mac OS X toggling the bar automatically resizes the window by the size of the larger bar, but doesn't include the smaller bar. Window Controller handles this automatically: on Mac it uses the final window size to calculate scaling and alignment and if the new window needs to toggle the status area, it adjusts the height to account for the automatic change.

Why view is special

To properly calculate dimensions the Controller needs to know the view state of the target window (i.e. Form, List, or Table; the two latter have a 3-pixel area on the left). But unlike the status toolbar or zoom level, view state is not a thing users will change on their own, so Window Controller doesn't attempt to save view state nor does it copy the state from current window. It either uses the default state or an explicit parameter; if neither is present, it assumes the view is Form.

blog comments powered by Disqus