Mark Scott

Sorry to be late to the party (apt metaphor for this day), but I also use an auto-enter calc to clean up edit-box data entry. I've recently begun using Debi Fuchs' Supertrim function, which, in addition to Returns, cleans up Tabs and Spaces quite elegantly.

Fantastic, LaRetta! Added to my toolbox.

One word of caution, raymanj: Tab panels are the most complex layout objects in FileMaker and many of their components are not exposed for styling in the Inspector. Also, the way the settings in the Inspector map to the various components of tab panels is not always obvious or straight-forward. Note, for example, the "header" area in your Onyx example that stretches to fill the space behind the three tabs. You have no control over that area; some themes have a tab-panel header and others (most of them) do not. Starting with a theme that is more complex (such as Onyx) increases the odds that your styling attempts will not get you where you want to go. Because most other layout objects are more exposed in the Inspector and thus more amenable to customization than the tab panel, it may sometimes make sense to start with a theme whose tab panel looks acceptable "out of the box" and work on styles for the other objects. Not saying your theme choice should always, or solely, be driven by tab panels, just offering a thought if tab panels are an important part of your layout designs. (Personally, I'm using tab panels a lot less these days, partly because they're hard to style, and partly because new layout object types, such as slide panel controls and popovers have largely obviated the need to tab panels; but that's just my approach.) Note, too, that I believe Onyx is one of the themes that FileMaker has deprecated. It'll continue to work, but FMI probably won't be doing much more development on that theme as new application versions come out down the road. hth, Mark

Symont, You might want to check out Todd Geist's Master-Detail module. It combines several intermediate-to-advavnced techniques (virtual list, layout-level triggers, and, in its original incarnation, Hyperlist [mostly replaced by the "ListOf" summary field type in the post-FMP13 era]) to break up screen real estate horizontally into navigation, record list, and detail panes. Perhaps this will provide some inspiration for you. Mark

There are several different naming-convention approaches that developers have used, not just for TOs, but tables, fields, variables, functions, etc. as well, some a bit more "geeky" and others more slanted toward being "highly readable." I like the naming conventions and coding practices promoted at FMStandards.org, which tend toward the "highly readable" camp, but YMM, of course, V. Mark

Hello noamb, Welcome back to the FileMaker fold. A lot has changed indeed! Here's the tutorial you should start with, by FM Guru Ray Cologon. I think it's just what you're looking for! There are others, but start with Ray's white paper. Then, when you're ready for a slightly more advanced approach, check out Todd Geist's video on the recent innovation of the Selector-Connector model, which builds on some of the concepts in Ray's paper, adding a further level of abstraction and flexibility. This approach, developed jointly by Todd and Jason Young, has been generating a lot of buzz over the past year. hth, Mark

This is the way I would approach it, Dr. Evil. It retains the benefits of button glyphs (state-specific styling, etc.).

Hey doughemi, In the spirit that you think it might just be a senior moment , are you sure you're looking on the correct tab of the Inspector? Irrespective of which theme you're using, you should use the "Control style" menu on the Inspector's "Data" tab. That's where you choose between Edit box, Drop-down list, Checkbox set, etc. I suspect you might be looking at the the "subcomponent" menu, which is the first (unlabeled) menu near the top of the "Appearance" tab. Because Edit boxes have no subcomponents for styling, that menu will not list any additional choices if the layout object is formatted as an Edit box in the Data tab. (Subcomponents come into play for other control types, especially in FM14, which introduced subcomponent styling for Checkbox and Radio Button sets, Drop-down lists, Popup menus, etc.) hth, Mark

Stephen, Wishing you a speedy recovery! Mark

Hey KC, In addition to the considerations mentioned by comment and Agnes, there is one more thing you might consider if your table is (or is likely to grow to be) large. JBante (who, I see, liked both of the above responses ) did some testing and found quite a difference in performance in record creation, finds, etc., between text and strictly numeric keys. Probably relates to comment's observation re index size. In many cases the difference will be academic, with little real-world impact, but it may make a palpable difference in some settings. I've tended to use Jeremy's numeric UUID function, but that's just my preference, and I've always been a fan of surrogate (meaningless) keys anyway. (BTW, if you need a multi-valued key, as in Selector-Connector for example, that can be a text field and still link to numeric pk fields.) hth, Mark

One thing you can try is placing an empty web viewer in the background of the modal window (filling the window and anchoring to the sides). Move it behind all fields and controls (obviously). Then, when you open the window, put focus into a field, which will gain the familiar "on-focus" outer-shadow highlight. Because of the web viewer background, which "catches" background clicks and prevents automatic commits, the user will be able to move between fields (of course) but not remove focus entirely from the window by clicking either in the background or outside. As long as the window is open, one field will always have obvious focus. Of course, your "Close" button should then commit any edits made in the modal window. hth, Mark

I know you've got a workable solution, jl, so consider the following just a thought exercise. LaRetta's comment about entering multiple requests ("vendor submissions" in this case) as lines reminded me of an approach I've used before. My goal was to be able to enter a list of specimen accession numbers, and then find those records in order to generate a "pick list" to carry back to our lab specimen freezers. In a nutshell, GTRR! A colleague would email me a simple, return-delimited list containing any number of accession numbers that she needed pulled. Then, I'd simply paste that list into a global field (must be a text field to accommodate return-delimited values), and Go to Related Record(s) via a relationship from that multi-valued global field to the actual accessionNumber field in the same table. GTRR itself is lightening fast, and it was simple to design the UI for it. As an alternative, a picker UI could also be used to choose the items to be found and populate the global. Just a thought.

One other thing to consider, jl, is whether you might want to extend your design in the future to support searching on multiple fields, say vendor and date range. A more standard approach, such as the one comment has advocated, is going to be more flexible and extensible. That said, FileMaker is forgiving, so there is nothing wrong with using the approach you've worked out, getting user feedback, and then, depending on that feedback (or simply on evolving user needs and business rules), changing the approach down the road. Let us know how it works out. Mark

Great tip! Vectors scale fine, but if there are horizontal or vertical edges in the design, those may fall between whole pixels upon scaling and thus get antialiased. It's not really visible on a retina display, but can be noticeable on a non-retina device. For the same reason, I find that it's also worth turning on "pixel view" in my illustration app to make sure edges fall cleanly on the grid (irrespective of whether I'm exporting as PNG or SVG). One thing that'a a bit hidden is that, in addition to being able to control overall padding around text and icon by selecting the "Button Bar: Segment" component, you can control the padding between text and icon by selecting the "Button Bar: Icon" component. Not sure if that helps, but worth remembering. Indeed! But somewhat counterintuitively, the rendering performance is actually better for PNGs, as they are already rasterized, whereas the rendering engine has to parse the vector data in SVGs in order to rasterize it for display. That point was made by Andrew Phan in his DevCon session, not to discourage using SVGs (and thus losing the dynamic styling capabilities and resolution independence of the SVG format) so much as to discourage designing overly complex SVG icons. (Surely it's a minuscule performance hit in most cases, anyway.) Once FileMaker rasterizes a given SVG, however, they attempt to cache the image data for further use and optimal performance. All in all, SVGs are clearly the way to go, from 14 on.

Many ways to skin a cat. Glad you got a good solution.