8 Replies Latest reply on Mar 8, 2013 3:38 PM by KevinElder

    Setting the Current Record and Reflecting Its Status

    RodrigoPerez

      Title

      Setting the Current Record and Reflecting Its Status

      Post

      I have been busy learning all kinds of things about scripting by trial and error, but have run into a couple of things that I could use some help with.

      First of all, it's not clear to me how to set a record as the currently active record.  I've found that I can do a search for a particular record in a table and that the following script actions will then modify that particular record, but is there another way or a more common/direct way of making a particular record active?

      Secondly, I'm trying to do something that is proving to be rather tricky or at least it's got me buffaloed.  I'm continuing development of my Projects database that has Tasks associated with each project.  As part of each Task, there is a Task Status field with radio button options for Active, Inactive, etc., and also a Task Priority field with radio button options for Emergency, High, Medium, etc., as shown in the attached screen capture below, which shows just the lower Task portion of the Project layout with the portal to the Task table.

      What I want to happen is to have the Task Status and Task Priority radio buttons display the current selections/entries for the record that gets selected in the portal.  Thus, when you click on a record in the Tasks portal, the radio buttons below will change to show you what has already been entered into the fields.  The record that has been selected also needs to remain the currently active record so that if I click on one of the Task radio buttons, that information is transferred into the currently selected record.

      Hopefully this is doable and once again, I've probably missed something obvious or fundamental, but I could sure use some pointers/tips right about now!

      FMPro_Tasks_Radio_Buttons.jpg

        • 1. Re: Setting the Current Record and Reflecting Its Status
          philmodjunk

          These are two very different issues.

          is there another way or a more common/direct way of making a particular record active?

          There are a number of ways, but WHICH record is the right one to select as the current record.

          In a table or list view layout, selecting a record as the current record is as simple as clicking it. A script can use go to Record to select a record as the current record from those in the current found set.

          The rest of the post describes a portal, not a found set so the options are different. You can still click a portal row to put the focus on that portal row but a script would use Go to Object followed by go to portal row to do the same.

          But the current record isn't much of a factor for what you want here. The key is in adding a second relationship to the portal's table and using a script to process the mouse click that puts a focus on a portal row and causes data from that record to appear in the fields below the portal.

          You currently have this relationship as far as I can tell:

          Projects::projectID = Tasks::ProductID

          You need a primary key for Tasks such as TaskID defined as an auto-entered serial number.

          Then add a field, often a global field, gSelectedTask defined as a number field in Projects.

          In Manage | Database | relationships, make a new table occurrence of Tasks by clicking it and then clicking the duplicate button (2 green plus signs). You can double click the new occurrence box to get a dialog to appear where you can rename the new occurrence box as SelectedTask.

          We have not duplicated a table. Instead, this is a new reference to the same table already present in your database.

          Add it to your relationships like this:

          Projects::gSelectedTask = SelectedTask::TaskID

          Put fields from SelectedTask on your layout to serve as your radio button fields below the portal.

          Write this script:

          Set Field [Projects::gSelectedTask ; Tasks::TaskID]
          Commit Record

          Use button setup to format the fields in your portal row to perform this script or add button for it in the portal row.

          You can use a conditional format on the fields in the Tasks portal to highlight with a different fill color when TaskID = gSelecteTask to show which portal row is the 'current' row.

          • 2. Re: Setting the Current Record and Reflecting Its Status
            RodrigoPerez

            First of all, it's not clear to me how to set a record as the currently active record.  I've found that I can do a search for a particular record in a table and that the following script actions will then modify that particular record, but is there another way or a more common/direct way of making a particular record active?

            Okay, let's take my original questions in two bites, so to speak.  Here is bite number one:

            Where I was going with this question was this...when working with the Tasks in the portal on my Projects layout, as soon as I click on a task record, that record seems to become the currently active record.  If I type anyting into the fields, it goes into the Task record that I clicked on.  If I set a variable equal to the Task ID Number (the unique serial number field for each Task) in a script that it triggered by clicking in the portal, I get the Task ID Number of the Task record that I clicked on.  In my way of thinking (wrong though it may be!) if I then switch to the Tasks table in my script, any following actions should still be carried out on the active Task record that was clicked on in the Project layout.  At the same time, I would expect that the radio buttons that display the Task record fields on the Project layout would also automatically change to reflect the values of the currently active record without me having to script anything or do anything fancy.  This is what would feel natural to me.

            In other words, what I was expecting was that there would be a mechanism to select the currently active record in a table.  Then, anything reflecting values from that table would automatically display info from the active record on a universal basis.  That was my train of thought as I initially started working with FM, but I now know that it works somewhat differently than that.  However, that's why I was asking about mechanisms to make a record the currently active record.

            I think that some of these issues would be helped by me reading a textbook, such as the 'Missing Manual' series, but the book for FM 12 isn't due out for another month.  It always helps tremendously to get at least some of the philosophy that went into the design of how everything works.

            I do have to admit, though, that I'm having a bit of difficulty in reading and understanding the script commands reference guide.  For some reason, I read through the description and think, "Oh, okay.  This script command is going to do such and such."  However, when I execute the script command and see the results, often times they are completely different from what I was anticipating.  One example is Go to Portal Row.  The text describes it as a mechanism to navigate to a particular portal row, but whenever I've used it with a calculated row value, it always brings up a dialog box asking the user to select the row that they want.  I'm not sure if this means my calculation is failing or if I've missed a parameter somewhere that would suppress the dialog box, but how to control this behavior doesn't seem to be mentioned in the description or examples.

            Okay, enough said on bite one.  On to the next topic!

            • 3. Re: Setting the Current Record and Reflecting Its Status
              philmodjunk

              when working with the Tasks in the portal on my Projects layout, as soon as I click on a task record, that record seems to become the currently active record.

              Yep, more specifically, that Portal Row now has the focus. What makes this a bit more complex to understand is that your layout still has a current record and this is separate from what portal row has the focus.

              if I then switch to the Tasks table in my script, any following actions should still be carried out on the active Task record that was clicked on in the Project layout.

              This is not the case. The current record on the tasks layout is fully independent of what row in your tasks portal has the focus. Consider the fact that you could have 20 different layouts that are all based on tasks and each could have a different current record, found set and sort order--if they all automatically synched to the same record because you clicked a portal row in a different layout, many database solutions would become much harder to work with.

              You can, howver, use go to related records as part of a script performed when you click a button in that portal row to take you to a designated layout based on tasks and bring up the record for the clicked row on that layout.

              At the same time, I would expect that the radio buttons that display the Task record fields on the Project layout would also automatically change to reflect the values of the currently active record without me having to script anything or do anything fancy.  This is what would feel natural to me.

              Again, this would make your current task simpler to set up but make many other layout designs much harder. I've shown you the standard way to make this work in my previous post. Feel free to post follow up questions on how to make that work for you if you still can't get that to work.

              One example is Go to Portal Row....

              Sounds like you didn't click the "Perform without dialog" check box that appears in the bottom left corner of the script editor when this script step is selected in your script.

              Rodrigo, answering questions like these are what this Forum is here to do, so don't hesitate to keep asking them. Wink

              • 4. Re: Setting the Current Record and Reflecting Its Status
                RodrigoPerez

                Now for the more tasty bite number two!

                I set everything up as you outlined in the second part of your post to get the radio buttons to reflect the data in the active record and sure enough it worked!  Thanks very much, PhilModJunk!  You're a great resource.  The only issue I have here is that I'm not at all clear what is actually going on here and why this method works.  If you don't mind, I'll break your information down a bit and then add my thoughts as to what I think is happening.  Then if you'd be so kind as to correct me, I'll hopefully come into the light!

                But the current record isn't much of a factor for what you want here. The key is in adding a second relationship to the portal's table and using a script to process the mouse click that puts a focus on a portal row and causes data from that record to appear in the fields below the portal.

                You currently have this relationship as far as I can tell:

                Projects::projectID = Tasks::ProductID

                You need a primary key for Tasks such as TaskID defined as an auto-entered serial number.

                 

                Yes, you're correct that there is an auto-serialized TaskID and relationship.

                 

                Then add a field, often a global field, gSelectedTask defined as a number field in Projects.

                 

                I added the field to the Projects table, but am confused as to what you mean by a global field and I could not find any option to make the field global.  That being said, wouldn't table fields be global in nature anyway?


                In Manage | Database | relationships, make a new table occurrence of Tasks by clicking it and then clicking the duplicate button (2 green plus signs). You can double click the new occurrence box to get a dialog to appear where you can rename the new occurrence box as SelectedTask.

                 

                I'm assuming (a dangerous thing to do, I know!) that this is the only way to create a many-to-one relationship in FM, by creating another reference to the Task table.  I haven't tried it, but what would happen if I just dragged another arrow from the gSelectedTask to the TaskID in the original Task table?  Would you either elaborate a bit further on the topic of these reference tables or point me to some documentation about them, please?  I'm really wondering what conditions tell me when to use this type of duplicated reference table.



                We have not duplicated a table. Instead, this is a new reference to the same table already present in your database.

                Add it to your relationships like this:

                Projects::gSelectedTask = SelectedTask::TaskID

                Put fields from SelectedTask on your layout to serve as your radio button fields below the portal.

                 

                All good through here!


                Write this script:

                Set Field [Projects::gSelectedTask ; Tasks::TaskID]
                Commit Record

                 

                When setting the field Projects::gSelectedTask to the value of Tasks::TaskID, how does FM know which record we're supposed to be dealing with?  I take it that it uses the one that we clicked on by default.  Then, the Commit Record command is what makes the radio buttons reflect the currently active record's information?  The reference guide doesn't indicate anywhere that it would cause this behavior.


                Use button setup to format the fields in your portal row to perform this script or add button for it in the portal row.

                 

                I just used the OnObjectEnter trigger to execute the script.


                You can use a conditional format on the fields in the Tasks portal to highlight with a different fill color when TaskID = gSelecteTask to show which portal row is the 'current' row.

                 

                I haven't yet played around with conditional formatting, but will give this part a shot next.

                 

                Again, thanks for all of the help you've provided so far!  Hopefully, it's clear that I'm having a fun time learning how to work with FM to build databases.  I'm still a beginner, though, so I always have lots of questions!

                • 5. Re: Setting the Current Record and Reflecting Its Status
                  GuyStevens

                  This is a demo file that shows the technique of selecting a records in a portal and then displaying it's fields.

                  Fields that you then can change.

                  The technique PhilModJunk is talking about.

                  http://dl.dropbox.com/u/18099008/Demo_Files/Books_EditionsV3.fp7

                  I don't know if this might be helpfull.

                  • 6. Re: Setting the Current Record and Reflecting Its Status
                    philmodjunk

                    I could not find any option to make the field global...

                    A global field stores only one value that is then accessible from any record on any layout in your file. It is an option often used for such a field as it enables two users to work with the same record on the same layout and yet be able to select diferent rows in the portal. It is not, however, a requirement to making this work for you.

                    To make a field "global", open Manage | Database | fields.

                    Find the field and double click it.

                    Click the storage tab.

                    Select the check box for global storage.

                    I'm assuming (a dangerous thing to do, I know!)...

                    It has nothing to do with whether the relationship is one to many, many to one or one to one. Using a new occurrence of tasks allows you to create a relationship between these two tables that is separate from the original relationship. If you just did a drag from a field in projects to the existing occurrence of tasks, it adds that as a new pair of "match" fields to the existing relationship--which will change what records appear in your portal--and not give you a relationship to use for your radio button fields. You might try this on a copy of your file and see what you get. you can double click the line between the two occurrences to see what you get when you do this. (By all means experiment with different options in FileMaker! It's a very good way to figure things out--just make copies so your experiments don't mess up your development copy.)

                    how does FM know which record we're supposed to be dealing with?

                    Good question and you are very close to the right answer. The mouse click on the button that performs this script sets the "focus" on that portal row and thus references to fields in the portal's record refer to those of the record you selected with the mouse click. It's really not a "default" setting as you'd have to write the script differently or change the layout design before the set field could refer to a different row in the portal.

                    I just used the OnObjectEnter trigger to execute the script.

                    That should work fine. I use that method if I need to edit the fields in the portal row.

                    You may find this tutorial on table occurrences helpful in understanding how to use them to get things to work in FileMaker: Tutorial: What are Table Occurrences?

                    It's an old thread that won't pop up in the recent items list if you post a comment to it, so post any questions it raises for you here or I might miss it.

                    • 7. Re: Setting the Current Record and Reflecting Its Status
                      RodrigoPerez

                      DaSaint,

                      Thanks for the link for the example database!

                       

                      PhilModJunk,

                      Thanks for all of your assistance and responses!  The example for Table Occurences was very enlightening.  It's really great to have the forum resources available like this with all of your expertise!

                      • 8. Re: Setting the Current Record and Reflecting Its Status
                        KevinElder

                             Sorry for resurrecting an old thread, but I have used the excellent information here and learned quite a bit - thank you!

                              

                             I have followed all of the details about highlighting a portal row. Since I want to be able to edit information in the highlit row, I would need to use the "OnObjectEnter" trigger to execute the script. However, this appears to be a FMP 10 and later command (I am using FMP 9). Am I stuck, or is there another way around this?