Jump to content

Dave Ramsey

Proof+Geist
  • Posts

    44
  • Joined

  • Last visited

Everything posted by Dave Ramsey

  1. Leland, That is *not* the way that’s supposed to work. 2 things I’d like to try: 1) If possible, can you send me a zipped copy of the full DDR to support@proofgeist.com? I understand if that’s not tenable for some reason. 2) If you have an opportunity, download DamageDetectoR, which is a free macOS utility for analyzing the DDR to identify common problems which occur with FileMaker’s export of the DDR. https://www.geistinteractive.com/products/damagedetector/ I haven’t seen a crash on initial load in *quite* a while, so something seriously funky must have occurred. Dave Ramsey
  2. Jeff, While reviewing the Geist helpdesk system, I saw that you had previously raised this issue with support. Todd replied with a query regarding your machine ID, but it does not appear as if you responded. Did you receive an email from Todd on February 4th? If not, check your spam filter to see if it got lost there...
  3. Jeff, My apologies for the difficulty. When you have a chance, can you send the same message to support@geistinteractive.com. Todd can help you get your trial activated. Thank you.
  4. Jonathan, There is not currently a single-step way to do that. The fastest way to do that with the current version of FMPerception would be to do a CSV export of the occurrences of the relevant script steps, and a CSV export of the scripts flat list, and then relate them in FileMaker. It's not optimal, but it shouldn't take more than about 5 minutes to get there... That said, I like the idea, and am likely to do something with it in a future version of FMPerception.
  5. Hey, Gilles, Excel has its own particular rules when it comes to CSV, particularly related to Unicode and line feeds. I did optimize that export for feeding back into FileMaker. It's been on my agenda to do some further checking to see if I can determine why Excel is being funky... But that agenda is a long list.
  6. Aside from the freeform text search, there really isn't a query maker (yet). That said, You can get there with two CSV exports bumped into FileMaker. 1 - Export Fields (flat), which will have which fields have repetitions, and what table they're in 2 - Export Layout objects (flat) (third query from the bottom), which has all the layout objects on every layout. 3 - Import both to FileMaker, and relate the two tables on field name and table name. This assumes that table names are unique... which may not be true in a multi-file system. In that case, add a predicate based upon the File Name field in both lists. Then, make whatever report makes the most sense to you. I don't know if you want to put the count of repetitions on the layout object list, or if you would prefer to make a portal of layout appearances on the field list... That'll depend upon your process, and what you're planning to do. Will that meet your needs?
  7. Gilles, You are correct, we have not talked about those much. Those 2 columns are patterned after the 4 columns immediately to the left, which flag if a named function is referenced inside the current item/row. I pre-defined 4 of them, but left 2 that you can define yourself. To use this feature, go to the preferences, and then the "Flagged Functions" tab. The right column has the complete name of the function you'd like to search for. The left column has the name of the FMPerception column that should show a dot when that function is referenced. A couple of notes: 1 - You can see that currently, User Defined 1 shows a dot when the position function is used. This is just an example. Feel free to override it. 2 - You can see that the ExecuteSQL() column gets a dot if the ExecuteSQL function is used, or if the @.sqlExecute function is used (from the SQL Sugar collection of custom functions). This is just an example showing that a single column can flag on multiple functions simultaneously. You can use this feature yourself, by adding the names of custom functions that you use that wrap standard FileMaker functions (like SQL Sugar wraps the ExecuteSQL function). This also means that you can override any of the function columns, not just the User Defined ones. If you want to make the Evaluate() column show a dot when the LeftValues function is used (for whatever reason), you have that option. 3 - There are no rows currently for User Defined 2. That's fine. You don't have to put a value for every column. You just have to use a value for every column that you want to see dots in. 4 - This feature searches only on functions (not variables, field names, etc), and only on the complete function names. If you're searching for a function called FormatZip, your function FormatZipPlus4 will not flag (unless you also add a line for FormatZipPlus4). The criteria are not case sensitive. 5 - Don't include the parenthesis in your function names on the right hand side. 6 - The intended use case for the User Defined columns was for a migration of some kind. Let's say that your system makes use of the trim() function, but that's causing problems because it's not handling trailing returns. So, you make a new custom function for SuperTrim(). Then, I'd make User Defined 1 look for 'Trim', and make User Defined 2 look for 'SuperTrim'. Load the DDR, and make all the dots in User Defined 1 move to User Defined 2. 7 - When you change the flagged columns, FMPerception will not update the results for currently loaded DDRs (due to FMPerceptions performance caching). You'll have to do a File -> Refresh or otherwise reopen the DDR. 8 - If you really mess things up in the Flagged Columns, there's a button to Restore Function Defaults, so you can get back to where you started. After typing all this up, I realized that we do have some documentation on this. Take a look at this page, which also has a video from Todd... https://docs.geistinteractive.com/article/60-flagged-functions-columns Does that clarify things? Do you have further questions?
  8. Gilles, Absolutely correct. It works with anything that FileMaker can copy and paste, so it works for tables, fields, scripts, script steps, layout objects, value lists, custom functions, and custom menus/menus sets/menu items. I don't think there's a way to mark something correct in this forum system. I'm just happy I could answer your question.
  9. Gilles, Since you copied table fields, you would have to paste them where table fields would go. So, go to your FileMaker database, Manage > Database, and then go to the Fields tab for the table you'd like to add those fields to. Click in the big field list area, and then Command-V to paste. All those fields should then appear in that table, just as if you had copied them all from within a FileMaker table using the FileMaker interface itself. Note that the definitions of some of the calculations may not carry over due to context issues (again, as if you had used FileMaker to copy/paste), so double check them before you make use of them. Does that answer your question?
  10. Sorry for the delay in getting back to you. Post DevCon, I've been sleeping for most of the last 10 hours. 🙂 Green - means that QuickFind is on, and the field is local to the TO for the layout, and stored. Yellow - means that the value is stored, but is at least one relational step away form the context TO for this layout. So, doing a QuickFind on this field will do a relational search. If you have quickfind turned on for this layout, you should minimize these. Red - means that the field in question is an unstored value (remote or otherwise), meaning that FileMaker must first calculate the value of this field for all recored (local or otherwise) before it can even begin doing a search. As a general rule of thumb, you should never leave QuickFind activated on a field like this. Note that these indicators pay no attention to if QuickFind is activated on the layout itself. If QuickFind is turned off for the layout, you don't have to worry about these, unless you would like to turn QuickFind back on. Does that make sense? Thank you very much for the kind words, Dave Ramsey
  11. 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.
  12. 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.
  13. 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!
  14. 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?
  15. Working on it... :-)
  16. 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.
  17. 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
  18. 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".
  19. 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.
  20. 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:
  21. 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!
  22. 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.
  23. For those who were interested, version 1.2.3 has been released with support for this feature. Thanks!
×
×
  • Create New...

Important Information

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