Jump to content

Dave Ramsey

Members
  • Content count

    34
  • Joined

  • Last visited

Community Reputation

1 Neutral

About Dave Ramsey

  • Rank
    FMPerception Developer
  • Birthday 02/04/1974

Profile Information

  • Gender
    Male
  • Location
    Delaware, Ohio, USA

FileMaker Experience

  • Skill Level
    Expert
  • FM Application
    16 Advanced

Platform Environment

  • OS Platform
    Mac
  • OS Version
    Sierra, Win 10

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Dave Ramsey

    Using the Diff Processor

    Hey, David. Andreas is correct. The current Diff Processor figures out which databases to compare based upon the names of the databases. It's helpful when you have a big multi-file system, but less so when you have 2 single-file versions that just happen to have different names. You can do it with a text editor, but my preferred way way would be to rename the local version and then export a new DDR. It's sub-optimal, I know. One of the core features of the next version of the Diff Processor is support for differing file names, but that's not yet ready for release.
  2. Dave Ramsey

    Printing The Call Chain Diagram

    Most of the "back-end" code for FMPerception is 95% the same between Mac and Windows. Of the remaining 5%, most of that is just punctuation. I've gotten pretty good at mapping Swift to C# and vice-versa. When I'm doing that work, the two code bases are up side by side, and everything is named pretty much the same. The big difference occurs when I'm interacting with the OS or the UI. The APIs for communicating with each are completely different, and I've taken to not looking at the code side-by side as I don't want the Mac way of doing things to hurt my Windows code. That can lead to this kind of difference, though it's not generally visible to the user. For that matter, this was never supposed to be visible to the user. It was just debugging code for my own personal use that lived too long. Normally I'd have just hidden it, but the users found it useful... and then I wanted to replace it with the menu option... so until the menu option comes in I didn't want to start renaming files that people might be making use of... And now it's all better.
  3. Dave Ramsey

    Printing The Call Chain Diagram

    By the way, the latest version of FMPerception (16.0.7) has an option under the File menu to export the Report Card or Call Chain Diagram HTML to a place of your choosing. While this is not directly provide print capability, it does make it easier to archive, transmit, or print (using your browser of choice). See the release notes for the latest version for additional details. Thanks!
  4. Dave Ramsey

    Printing The Call Chain Diagram

    So, there's a relatively simple way to do this. I haven't directly implemented printing support yet for either OS (definitely non-trivial). But, when generating either a call chain diagram or a Report Card, the HTML is saved out to disk each time you make one. Windows: The file is called htmlDump.html. It's on the desktop. Mac: The file tempDump.html and it is in the Documents directory. So, bring up the relevant call chain diagram, and then find the exported html file on your machine. It's not elegant, but it's there. Good enough?
  5. Dave Ramsey

    Comparing Layouts in a file.

    Working on it... :-)
  6. Dave Ramsey

    Finding Webdirect Incompatible Scripts

    It's on the list. :-)
  7. Dave Ramsey

    Finding Webdirect Incompatible Scripts

    There is not (currently) a feature in FMPerception for checking WebDirect compatibility. Generally If I'm trying to do the with FMPerception, I know the kinds of steps I've added that will cause incompatibility. Drilling down through the Standard Script Steps query will allow me to quickly see all the places in the system where I used certain kinds of steps. For now, that's the best option available in FMPerception.
  8. Dave Ramsey

    Find script triggers that call a script?

    Gotcha. Happy to help.
  9. Dave Ramsey

    Find script triggers that call a script?

    Close. FMPerception treats the triggers themselves as objects of their own. So, when looking at the script, you can select the References sub-query and see everyplace the script is referenced. Layout triggers get a black flag icon. Layout object triggers get a white flag icon. A Layout trigger row has a sub-query to locate the parent layout. A Layout object trigger has a sub-query for the layout object hierarchy. So it till show the owning object, any object that contains that object, and object that contains that object (and so on), up through the layout and layout folders that contain all of it. So, you don't get the objects themselves, but you get the triggers, and the object is about 2 clicks away from each. So, question for you: Is this what you need, or do you have a particular use case that needs something different / flattened? Thank you, Dave Ramsey
  10. Dave Ramsey

    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".
  11. Dave Ramsey

    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.
  12. Dave Ramsey

    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:
  13. 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!
  14. Dave Ramsey

    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.
  15. Dave Ramsey

    Default sort order override

    For those who were interested, version 1.2.3 has been released with support for this feature. Thanks!
×

Important Information

By using this site, you agree to our Terms of Use.