Jump to content

bruceR

Members
  • Posts

    4,017
  • Joined

  • Last visited

  • Days Won

    52

bruceR last won the day on November 20 2023

bruceR had the most liked content!

4 Followers

Profile Information

  • Gender
    Male
  • Location
    Redmond WA

FileMaker Experience

  • Skill Level
    Expert
  • Application
    18

Platform Environment

  • OS Platform
    Mac
  • OS Version
    High Sierra and El Cap

Claris Partner

  • Membership
    Claris Community

Recent Profile Visitors

37,878 profile views

bruceR's Achievements

Grand Master

Grand Master (14/14)

  • Very Popular Rare
  • First Post
  • Collaborator
  • Posting Machine Rare
  • Conversation Starter

Recent Badges

165

Reputation

16

Community Answers

  1. While comment's suggestion works, I experience a few problems with it. Consequently, I always add a calculation field to my tables, and make it unstored, get( recordNumber). See attached example file and screenshots. The advantage of using a layout variable is that you don't need to modify the field definitions. The disadvantage, in my experience, is that any time you touch the formatting of the variable, it resizes itself. SimpleRecNum.fmp12
  2. Glad you have found it useful. It's a good staring point for you but there are certainly things I'd change or improve. Others may or may not jump in to demonstrate some of those improvements, by modifying this file or contributing their own.
  3. I updated the example to take away a few of the messy parts.
  4. Comment has suggested a much more relational approach. Attached is one take on that, hopefully it will give you some ideas. It uses tables for Patients; CASES; CaseCharges (line items); FEES; and a PROCEDURES table and associated ProcedureCharges table. It is in a semi-polished state, some things are in place that I was just testing. CHARGES_TEST modBFR.fmp12
  5. As stated by comment; you don't select it using the TYPE field. CardsMyExample MODB.fmp12
  6. " I have 2 tables; CARDS and TYPE" Nope. You have two tables; PASSWORDS and TYPE. Nothing about your design requires TYPE to be unique.
  7. Help will be impossible until you specify user name and password for your TEST file.
  8. Why? Why do you think you need to do this?
  9. It’s generally a lot easier to understand a complicated request if you post a clone or an example file.
  10. What you have quoted is erroneous. There can be no double quote in the go to field statement. But delete that line anyway; it isn't needed. Instead: Go to Layout ["Client Data" (Client Data) Replace Field Contents [ No dialog ; Client Data::New Emergency Date ; ""]
  11. Note that this exact same subject is being discussed on FileMaker Community. https://community.filemaker.com/thread/184913
  12. I'd suspect something else then. Some conditional formatting or hide calc, some ill-written custom function, even your data viewer watch functions; something is declaring that variable. The fact that you can't post a full and complete script - is also troubling. Have you got Advanced? Can you generate a DDR?
  13. Where is your actual script? How are you triggering the script? Can you show us your file or a simple example file? There will need to be a second step in the script so you can stop in debugger and look at the variable contents before the script ends. Since you are using a script variable ( single $ variable) it will always be empty after the script runs. While this is something you should be able to do successfully - in real life, what do you want to do with $fieldName?
  14. WHICH two layouts? No, they are not independent of each other. They are based on the same table. Your entire premise here has been to do something "not the parent" which makes no sense, and you have been unable to explain.
  15. What does select mean - to you? And after "selecting" - what is next? What are you actually trying to do?
×
×
  • Create New...

Important Information

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