Jump to content

Dave Ramsey

Members
  • Content Count

    40
  • 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

    Export to CSV, strange Excel File

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

    User Defined columns

    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?
  3. Dave Ramsey

    User Defined columns

    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?
  4. Dave Ramsey

    Copy for FileMaker

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

    Copy for FileMaker

    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?
  6. Dave Ramsey

    Help for column symbols

    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
  7. 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.
  8. 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.
  9. 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!
  10. 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?
  11. Dave Ramsey

    Comparing Layouts in a file.

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

    Finding Webdirect Incompatible Scripts

    It's on the list. :-)
  13. 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.
  14. Dave Ramsey

    Find script triggers that call a script?

    Gotcha. Happy to help.
  15. 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
×

Important Information

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