Dave Ramsey

  • Content count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About Dave Ramsey

  • Rank
  • Birthday 02/04/1974

Profile Information

  • Gender
  • Location
    Delaware, Ohio, USA

FIleMaker Profile

  • FM Application
    15 Advanced
  • Platform
    Mac OS X El Capitan
  • Skill Level
  1. 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:
  2. 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!
  3. 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.
  4. For those who were interested, version 1.2.3 has been released with support for this feature. Thanks!
  5. 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
  6. 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. :-)
  7. 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.
  8. 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. :-)
  9. 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.
  10. 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.
  11. 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.
  12. Biggest single file is now 303.8 MB. Thanks!
  13. 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.
  14. I'm looking for some DDRs that I can use to torture-test FMPerception. --The biggest multi-file DDR that I have for testing is 1.06 gigabytes. --The largest single-file DDR is 224 megabytes. If you've got something larger, and you can allow me to use a copy for testing purposes, I would love to hear from you. As larger DDRs are provided, I'll update this thread with the new numbers to beat. :-) Let the games begin!
  15. Currently, the diff tool is not designed for that use case. It kind of depends upon the kinds of changes you're interested in examining.... Option 1: Open the same DDR twice. You can open a new DDR browser, and point it at the same DDR again. Then, you can have 2 windows that are both looking at the same file, but at different layouts. This is still a visual comparison, but it does also give you access to the information in the Detail if that helps. Options 2: You can save (for example) the list of layout objects from each layout to a CSV. Then, you can compare those two files. Personally, I use BBEdit when doing there, but there are all sorts of text-file-to-text-file diff tools. Granted, this won't tell you if one of the objects was resized, but it'll get a lot of the large, functional elements. You could also dump both CSVs into FileMaker and create something more fiddly comparison-wise, depending upon what you're trying to find. If these won't help, perhaps some more details about what you hope to find in your comparison would be helpful. Dave Ramsey