A Quick Caveat
Many of the things that we "know" about the way that FileMaker works behind the scenes are only from black-box testing. We press the button, see what happens, and attempt to infer the rules that are causing the behavior we observe. Any of the information here about how FileMaker works in the background is based purely upon our observations, and has not been confirmed or validated by anyone at FileMaker Inc. If anyone can provide additional details about any of these questions, please let us know. Thank you.
System requirements
Access Requirements
Layout Mode. You have to be able to get into layout mode on the particular layout to access the layout elements.
What does "Enable access for assistive devices" do?
It allows AppleScript access to to the UI. It was originally designed to allow makers of input devices for the differently-abled to model more advanced behaviors than just mouse movement and keyboard clicks. In this case, it allows fmXRaySpecs to AppleScriptably control FileMaker in ways that FileMaker Inc did not originally support. For example, there is no AppleScript command for entering layout mode (much like there is no FileMaker script command to do so). Using UI scripting, fmXRaySpecs can ask FileMaker to enter layout mode.
How does it work?
If you copy a group of layout elements in FileMaker Pro, 2 things are placed in your clipboard:
Wait, this works in FileMaker Pro? Non-Advanced?
Yes. Every feature.
But FileMaker Pro can't see tooltips, right?
FileMaker Pro itself can see them (otherwise it couldn't display them for you). It just doesn't provide an interface to allow the user to see or edit the definition of tooltips. However, if you copy a layout element that has a tooltip, and paste it on another layout, FileMaker makes sure that any tooltip that was defined on that element goes along with it... and so it appears in the XML for the layout.
So, I can edit tooltips using this, even if I don't have Advanced?
Sorry, no. fmXRaySpecs does not allow a user to edit any of the properties of any kind of layout element, including tooltips. You can see how they are defined, but by design (and for safety and security) fmXRaySpecs doesn't send any information of any kind to FileMaker. It only requests information and then displays it.
Do I have to change anything in my solution to make this work?
No. fmXRaySpecs requires no special scripts, field definitions, layout elements, or naming converntions. Nor do you need to have any FileMaker plugins installed. As long as you meet the system and access requirements, everything should work properly.
Will fmXRaySpecs change anything in my solution?
No. Well, probably not... That's up to you. fmXRaySpecs gets the layout data by going to FileMaker and sending the following key sequence:
That's all. However, if you have used Custom Menus to override any of these default key commands, fmXRaySpecs will fail to work at best, and do something catastrophic at worst. If Command-L is a shortcut in your system for "Delete all customers", you should really not use the standard process
fmXRaySpecs will make an effort to confirm that Command-L will send FileMaker to layout mode. It looks for a menu option called "Layout Mode", and makes sure that this menu option has a shortcut of Command-L. If either of these is false, fmXRaySpecs will refuse to run. It will, however, notice if you have moved the Layout Mode menu option (say, to a developer menu). In this case, however, the process of finding and validating the menu option takes a couple of seconds. If you find that fmXRaySpecs seems to pause for a bit before actually getting to work, that's the most likely culprit.
This test is skipped if you are already in Layout Mode, so you'll get the fastest turnaround if you run it from that mode.
fmXRaySpecs copies the layout... What about what was in my clipboard before I used it? What happens to that information?
Before fmXRaySpecs copies anything on your layout, it sets aside a copy of whatever is in the clipboard. After pulling all the information from the layout, it restores your clipboard to its pre-pull state.
This information about conditional formatting seems really thin. Why is that?
Conditional formatting presented a unique problem. A single field can have a virtually unlimited number of separate conditional formatting instructions. We're working on some ways to interact with this information, but for now, here's what you can do:
Is there any ability to set tolerances or flags when a field is too big / too small / misaligned, missing a trigger, etc?
No, there isn't. In general, a sort and maybe a search will tell you what you really need to know. Depending upon interest, this may be something that gets added in a later version. In the meantime, if you've got one of those monster projects where you have to clean up 50,000 fields on 1,000 different layouts, drop us a line. We may be able to roll a custom version for you that will highlight just the issues you're most concerned about.
I really want to sort the fields in tab order. That would be really helpful! Why can't I see the tab order?
Unfortunately, for some reason, the tab order is not in the XML. This helps to explain why when you copy and paste a group of fields, the tab order is often broken. FileMaker is using the XML for their own copy/paste function, so they don't have the tab order either.
If and when they add support for the tab order in the copied XML, we'll be adding support for viewing the tab order in fmXRaySpecs.
Things that are not in the XML
Comments