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.

Hi jl, I agree with comment that the custom dialog approach might not be the most graceful way to script a find . . . and with Kris that your goal should be to support FileMaker's native Find functionality (particularly multiple find requests, as Kris mentioned) as much as possible, even as you script the process and put a more intuitive interface on it. Assuming you want to stick with, and build upon, the custom dialog approach, and if you can limit your users to searching a maximum of 3 submissions at a time—is that a reasonable assumption here?—then you could: (1) give them 3 input fields (make them global fields, out of which you'll grab user input with successive loop iterations); (2) limit your loop to up to 3 iterations (depending on how many input fields are filled in); and (3) create a New Request with each loop, one request per input field, populating your actual submission field from the global inputs. See if that works for you. (Personally, I'm not sure I'd do it this way, as I intimated above, but it may be worth exploring.) Mark

Hey Dr. Evil, In your shoes, I'd probably just go ahead and create the separate edit box styles. Apply the basic one (i.e., sans state-specific effects) to your edit boxes, then when you want to attach a button action to an edit box, it's just a quick click in the Styles Inspector to switch it over. There's very little overhead to defining extra styles and saving them to your theme—certainly a lot less than not creating the styles and adding local-styling overrides to objects. That was a key message in some of the DevCon sessions in the past couple years. So that's how I'd handle it at least. Let us know if you come up with another approach. Options are good. hth, Mark

Hello comment, I agree that the "SVG Grammar" white paper recommends "ensure that the fill color is not explicitly set on the element in the SVG image file" and that "FileMaker Pro adds a top-level <g class="fm_fill"> element to the SVG image before the image is saved in the FileMaker Pro file." (That is, FileMaker will not automatically add the class="fm_fill" property if the fill="#XXXXXX" property is not first removed, as confirmed in my testing.) If, however, upon opening the SVG file in a text editor (which you'll need to do to remove the fill color anyway*), you leave the fill color property in place and simply add the class="fm_fill" property immediately after, then the icon will display white (assuming a fill color of #FFFFFF), rather than black, in the Button Setup HUD (similar to the built-in icons) and still be able to be styled through the Inspector or conditional formatting. Emory Brown, over at dbservices, has a nice writeup on this topic. (*DataManix's SVG Gallery Tool automates the task of inserting the class="fm_fill" property into the correct position, obviating the need to open the SVG file(s) in a text editor. It can process entire folders of icons in one fell swoop. Thanks to Claus Lavendt for this tool, and, of course, to voltron2112 for his Indats Icon Manager file as well.)

Very nice work, Bruce! Sure to come in handy. Mark

Can you capture the calculation logic into a custom function, and then cite that in both the conditional formatting expression and in a guard clause in your script? That would allow you to maintain the underlying logic in just one place (DRY). Just a thought.

Just to add to the options . . . there are also some good ideas, and well-articulated debate!, over at FM Standards.org re ideas for formatting ExecuteSQL ( ) calcs so as to facilitate debugging.

Hey Stephen, Thanks, as always, for all that you do in maintaining this invaluable community resource! One organizational change that I'd love to see would be moving away from a design that encourages Thread Starters to figure "well, I'm currently using (or learning!) version 14, so I suppose I'll ask my 'portal' (etc.) question there." Nine times out of 10, it's a question that crosses version lines, not relating at all to the new features of said version. I'm not certain of the best way to encourage posters to scroll down and find the more appropriate categorical forum; changing the title "FileMaker Pro 14 General Discussion" to something like "FileMaker Pro 14 New/Changed Features Discussion" may help a bit, and similarly for the other version-specific forums. Granted, some posters, particularly those very new to the platform and feeling a bit lost, are probably unsure just where to post their questions, so a generic "FileMaker Pro General Questions: For questions that don't fall into another particular forum" category would probably still be helpful, but maybe would work best if it's positioned down the list a ways, below the more specific categorical ones. - Just a thought. Mark

Another option — not necessarily better than Don's, but having options is good — would be to leverage Selector-Connector (if you've already got that approach in place, that is). Set the respective "id" field in the Selector table to the current record's id, then GTRR from that table to the connected occurrence of the current table. In S/C, each main table usually will have a second occurrence hanging off of the Selector table, so it avoids adding a TO just to provide the functionality of isolating the current record. - Just a thought. BTW… Couldn't agree more, LaRetta! Thanks for reminding us of that. Mark

Hi Michael, Agree with eos (and Miss A) that the Radio Button set is the correct UI device for mutually exclusive choices. Note that in FileMaker, a user can choose multiple options even in Radio Button sets by using the Shift modifier key, so eos' auto-enter calculation is an essential tool to keep in your toolbox whenever enforcing single values is paramount. That said, for Boolean "Yes/No" fields (putting aside the "threee-value logic" Yes/No/NA case you mentioned), the simplest UI approach is often a single checkbox, where the checked/unchecked state represents your "yes" and "no" values respectively. My approach for handling this is to place a single checkbox on the layout tied to a "Boolean True" value list with only the single value "True" (or 1), hide the value itself — the field label will identify the semantic meaning of the control — and set the field to this auto-enter calc: GetAsBoolean ( Self ) I also auto-enter data (either 0 or 1) to set the default value for new records. This way checking/unchecking the box will toggle the value between True and False, and the multiple-value problem is eliminated.

I totally concur with your assessment, Jarvis ! The ability to record additional information about each task would be reason #3 for going with a normalized design. Let us know how it turns out. Mark