We have reset all users FileMaker related profile fields. Please take the opportunity to update your information,  this will provide background to members whom read your posts. Click here.

Jump to content

Dave Ramsey

  • Content count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About Dave Ramsey

  • Rank
    FMPerception Developer
  • Birthday 02/04/1974

Profile Information

  • Gender
  • Location
    Delaware, Ohio, USA
  1. Broken References

    Yes, you are correct that some of the issues might have indirect references. For example, if a script has a problem, it might be inferred that any layout (or menu item, or other script) that calls that script also has a problem... But that's beyond the scope of the current functionality. What I don't want to do is tell a user that there is a problem in Script X, when the problem is that it validly calls Script Y, and Script Y is the one that actually has the problem. The "Impacted" list is more about where you have to go to fix the issue. The total number of occurrences of issues is on the first line of the Broken References section of the report card. That number should be equal to the sum of the items on the Broken References query node. If I were talking to a customer, I would either quote them that first number form the report card, or I would quote the sum of the other lines on the report card. So either "here are the number of issues", or "here are the number of FileMaker objects that are objectively broken in some manner".
  2. Broken References

    Hey, Lee. Great question. The Broken References top level query is organized by the kind of error that is encountered, but provides very little assistance for where there errors are encountered. So, for example, an "Empty Layout Reference" is commonly found in a Go To Layout or Go To Related Record step that was pointed to a layout that no longer exists... But that could appear in any of the following: Script step Single step layout object button Single step Menu item So, if you wanted to fix all the "Empty Layout Reference" items, you might have to go all over the place to do it. Some users requested the ability to tackle broken references by where they occur, rather than by type of error. So, "let me go to a particular layout and fix all the issues there (regardless of the kind of issue) before moving to another layout." The Report Card breakdown of Broken References is designed to assist with this. Additionally, I can use my own knowledge of a system to filter that list. So, if I have a bunch of Impacted Layouts, I can click on that to look at the layout list. The names of those layouts may tell me that I don't have to prioritize fixing these, as I tagged the Layout names with "[DEPRECATED]" (my personal favorite code for tagging items that are not in use, but that I haven't gotten around to deleting yet). Or, all issues may be on my Main Menu layout... A serious problem that I should address immediately, one way or another. The behavior difference between the two lists is also more in line with how I see the Report Card working. If I'm about to sit down with a customer, a sense of what user elements are effected by this issue is far more useful to me than a technical explanation of the kinds of issues. So, in the end, if those numbers match between the two different representations of Broken References, it is purely coincidental, because they're reporting two different things. If that does not answer your question, please let me know.
  3. FileMaker Plugin Registry

    Since FileMaker 16 now exports a plugin "source" code with the DDR (even if the plugin is not present) for plugin script steps, it would be helpful to have a way to identify a plugin based upon this "source" code. It would be immensely helpful if developers could provide this information. For reference the "source" code that I'm talking about is "FMmp" in the sample plugin source code. In the interest of gathering this information, I whipped up a Google Form for data collection. To reduce misuse, this form is entry-only. Once created, there is no way to edit a record. If the information changes over time (say, you would like users to go to a different URL), just make a new record. I can't speak for everyone else, but FMPerception will likely be using the last record available for each source code. At some later date, this may be expanded into a larger registry, but for now I'd just like to get some data. Follow this link to fill out the form: FileMaker Plugin Registry Form I don't have any interest in being the only person with access to this information, so if you would like to view the results, feel free to click here. Plugin Registry - Google Sheets If there is some other registry, just point me to it, and I'll apologize for the distraction. Thank you very much. Dave Ramsey P.S. Here's an example of how it looks when FMPerception knows about your plugin:
  4. I'm working on a feature for a forthcoming FMPerception version to manipulate the TopCallStats.log files generated from FileMaker Server 15, and I'd like to get ahold of some real test data to work with. I can manufacture test data all day, and it won't be nearly as helpful as a couple of real logs generated from real servers and real solutions. I'm hoping to find a couple of developers who can generate logs and provide them along with the associated DDRs. For the sake of privacy, it might be best to contact me directly at dave@workflowdata.com. That said, I'll be happy to answer any questions here or there. Thank you very much!
  5. FMPerception won't open in 10.9.5

    Hello, Larry, Yes, FMPerception for macOS is currently limited to 10.10 and higher. That's the oldest OS for which we've performed the appropriate due diligence to be able to confidently state that FMPerception can happily handle that version. I don't anticipate future support for an older OS. My apologies for providing exactly the response you were hoping not to hear, but it's the best I've got right now.
  6. Default sort order override

    For those who were interested, version 1.2.3 has been released with support for this feature. Thanks!
  7. Default sort order override

    Hello, my ad-hoc steering committee... I'm shortly going to be tackling allowing an override of the default sort order. Once implemented, there would be a preference to override the default sort order for all(-ish) queries to sort alphabetically, rather than by export / creation order. I would love to get some feedback on this idea, in particular that I'm not either targeting too narrowly or too broadly. My thought is that this could be best implemented using 3 checkboxes. Sort almost everything alphabetically by default Sort Layouts alphabetically by default Sort Scripts alphabetically by default I think that for most users, sorting fields, TOs, references, etc by name by default will not cause a problem. Most of them won't even need a preference for that. They'd like it always on. I have, however, identified users that would like to retain general access to the imported sort order. I've identified Scripts and Layouts as two elements that very commonly are manually ordered. Most developers will group similar layouts and scripts, even assuming that they have a naming convention that would allow for meaningful interaction with these elements (say, Scripts) alphabetically. I also don't think there's any value to sorting Layout Objects in anything other than import order (by default), as the import order is a parent-child aware z-order. I'm also thinking that this will necessitate the addition of a column in the Results pane that stores the creation / import ordinal so that you have the ability to restore that order (or reverse that order) if necessary for a single query. Questions: Can you think of any other elements within FileMaker whose creation / manual order is far more important than their alphabetical order? This is oft requested enough that I'm considering changing the first checkbox (sort most items alphabetically) to ON by default. I think I will have fewer users asking how to change it back than I currently have users asking how to turn it on. Thoughts? While neither the Hierarchy Browser nor the Columnar Browser have a base implementation for overriding the sort order on an area by area basis, I might try to invent one if there's huge desire for it. I still that most users will never tweak the default, but I'm willing to be proven wrong. In a fever-dream, I thought that instead of adding checkboxes to the preferences, I would add menu items that could be toggled on and off. This only becomes of use if somebody sees being able to override this on a document-by-document basis, and really regularly, as a critical requirement. If this is you, I'd like to hear from you. I'm pretty sure that the overwhelming majority of users will turn it on, and never mess with it. Most will never even override that default sort to use the new import ordinal column. Any other thoughts or ideas related to this topic would be most appreciated. Thank you very much, Dave Ramsey
  8. Does anyone have any ideas for things that FMPerception could do with the Touch Bar? My first thought was mapping the back arrow onto the Touch Bar. Also, maybe Refresh? New DDR / New Diff? What would you like to see? P.S. This is not going to suck a lot of time from more universal features. If the tools don't make it *very* easy, I'll wait for the next version of the tools. :-)
  9. Broken references in inactive calculations?

    The more I dig into this, the more I think the right answer is to ignore references (broken or otherwise) in "unexpressed" code. I received a DDR via support request that had a value list that used to be dynamically generated from the contents of fields, but is now statically defined. In the DDR XML, the references to the old fields are still there. If you deleted one of those fields, now it would be a broken reference, but it really just isn't. Additionally, based upon the current rules (of considering unexpressed references), that value list is keeping those fields from being "unreferenced"... and that's even harder to justify. Changing the rules to ignore unpressed references will (I believe) only have an impact on a user who's trying to figure out what the code used to be, while the current rules are having a much broader impact. While it's going to be a lot of fun to filter them all out, I think they need to go. That said, I'm still interested in impassioned pleas to continue to pay attention to them.
  10. Broken references in inactive calculations?

    That *should* be how it's working now. An inactive calculation with no broken references should not appear broken. I would consider anything that responds otherwise to be a bug, and would love to receive a bug report. :-)
  11. Currently, FMPerception will flag a broken reference in a calculation definition, even if the calculation has been deactivated. So, if you have a broken reference in an auto-entry calculation, but the auto entry calculation checkbox has been turned off for that field, FMPerception will still bring it to your attention. I'm starting to suspect that this is overly aggressive. I mean, it's technically correct... The calc is in your database, and the calc has a broken reference... but do we care? I *do* remove broken references in deactivated script steps. So, either way there's an inconsistency. I'm interested in arguments either direction, but I'm probably most interested for arguments to keep the functionality as it is. I'm currently inclined to remove these broken references from the broken references results. Thoughts? Thank you very much.
  12. Request for HUGE DDRs

    Lee, That would definitely help you to reduce the local CSS of a specific problem layout. My point was just that I'm not sure that looking at that at a file-level is optimal. Is it worthwhile to spend the time to optimize every local CSS node out of every layout? My sense is that it's not, but I don't have any math to back that up. It feels like "premature optimization". Definitely. Node counts in local CSS I think are really useful, and I'd like to work on some code to allow me to display those higher in the hierarchy (at the layout level, rather than just at the layout object level like now). That said, I don't want to kill the performance of a tool optimized for performance. It's a tricky balance to maintain. I'm less convinced of the value of the character count of the overridden nodes. There's a line between optimizing the layout and optimizing the DDR itself... and that's probably over that line. I also like the idea of looking into which nodes are most often overridden. That could be helpful.
  13. Request for HUGE DDRs

    Wim, As far as I can tell, the DDR doesn't contain many/any Base64 graphics representations anymore. They appear to have disappeared around about FileMaker 12. It's in the clipboard XML, but not in the DDR XML. I wish it was still there. I had some cool ideas for what to do with it. I was curious about the answer to your question, though, so I wrote a little tool to analyze DDRs to determine where the size was coming from. I analyzed half a dozen big files to determine what percentage of the total character count of the DDR was tied up in each major element, and found the following: In general, I'm seeing that DDRs are about 70-80% layouts, 10-20% scripts, and generally less than 5% "everything else together". Within the Layouts XML, 60-70% of that is styling information (LocalCSS, character and paragraph styles, and number/date/time formatting). That last one is possibly the worst, as it's verbose and present on basically everything (the DDR exports number/date/time formatting for web viewer objects…). It accounts for effectively about a third of the size of the layouts. Optimizing styles and such has no impact on it. If you could remove ALL local CSS, it's likely going to save you about 10-30% of your DDR size. I wrote the code, but I can't come up with a really good argument to roll it into FMPerception. It's interesting, but I haven't been able to come up with any particular use for the information (aside from triggering an OCD reaction from some developers). If somebody has a good argument for why it might be legitimately useful, I'll consider adding it to FMPerception. But the numbers that I have suggest that it isn't a reliable measure of the complexity of a system, or even of its performance. I am willing to be swayed, though. Wim, thanks for the awesome question.
  14. Request for HUGE DDRs

    Biggest single file is now 303.8 MB. Thanks!
  15. See all scripts that reference a layout

    No, you aren't missing anything, per se. It's just something that hasn't been tackled yet. It's on the list. In the short term, use the global Text Search function (not the one inside a particular layout) and run a search for the layout name. If the layout name is too common to generate meaningful results, try renaming the layout (perhaps in a clone), and then regenerate the DDR. Depending upon your naming conventions, this may result in exactly the list you're looking for (with the addition of the layout itself appearing on the list). Please let me know if that doesn't meet your needs. Dave Ramsey P.S. Watch out for indirection. Targeting a layout by calculated name or calculated number is one of the oldest FileMaker indirection functions available.