A bit more progress!
As I continue to fiddle with this script and the layouts, I've successfully established the portal row data in variables. The card layout with checkboxes for singer names correctly enters initials (not full names because of space in the Gigs layout) into the Roster field.
The card looks like this; the two fields at the bottom are for reference while I'm working on this and represent the actual record from the gigs_PERFORMANCES table (i.e., verifying the $$ variables at the top).
My script so far which is invoked from a button on the Gigs layout is this, with a script trigger on the card layout to perform a find of the current PerformanceNo.
how can have the Roster field contents appear on one line? Currently, for each checkbox selected, the initials of that singer are entered on a separate line. I'd prefer something like "CK | VSH | MA" to appear in the Roster. That way, when printing the Gig setlist, all initials show.
This is the table view of gigs_PERFORMANCES which shows initials on separate lines:
I have another field called RosterFMN, which is meant to contain the full name of the singer. My checklist is populated with a value list that includes Intials from the Singers table and Performername (full name). Based on the checkboxes selected which enters the singer's initials, I'd like the RosterFMN field to be populated with the singer's full name.
As a side note to 1 above, if possible, I'd like to sort initials so that they are displayed consistently on the set list. Currently, they are shown in the order they are actually clicked/selected on the card layout.
Not a direct answer to your most recent questions, but a couple of thoughts that I would like to plant at this stage of your solution's development:
I am curious if there is a good reason for using the script trigger to navigate to the target record based on the value stored in a global variable. If there is not a good motivation to break things apart in this way, then I would suggest considering performing the Find step as part of your button script, i.e. starting at around line 17, and getting rid of using the script trigger on the layout.
I suspect that you are storing some values in global variables because you anticipate needing those values later on in the process of updating/saving a change to the various record(s) involved. I suggest keeping keeping your mind open to the possibility that it may not be necessary to store these values in global variables, either because you can store/pass the values that you need using just local variables, or that the values may already be available to the script that needs them, because that script will already have access to the context that it needs to obtain these values. I am not certain that the above will be the case, but I have a hunch that it is more likely than not.
My motivation for mentioning the above:
Eliminating script triggers and global variables which are not necessary to a clean implementation of functionality is almost always a step towards having more maintainable code.
Very good questions! If you saw earlier posts in the thread, I was/am having trouble actually accessing the current portal record. I discovered that while I thought I was editing the current record, I was in fact editing the first record of the portal. So the globals helped me find the record I wanted.
Passing portal row-specific parameters to the script (perform script (parameters)), the script retrieving these parameters (get script parameters ) may remediate those issues.
For reasons I don't understand, clicking the button in the portal record to invoke the script does not actually pull the portal record in the card layout, but instead pulls the first record in the portal. While I think I should be able to do all of this in one script, I just cannot make it work.
That said, using a script trigger on layout enter of the card to find records in the portal TO seems to work. My issue now is that instead of having each checkbox enter in the Roster field as a separate line, I want them to all appear on a single line. Again, I'm baffled.
Make sure that the button is completely within the portal row. Click in layout mode the portal and move it with an arrow key. If the button moves also then it is connected with the portal. If the button stays at the same place when you move the portal, then you have to size the button a bit smaller and move it exactely into the portal row.
Getting only the first record of the related table points to that issue.
Not sure if this is a workaround or an an expected method of handling the multi-line entry issue, but I created another field in my table called RosterDisplay. It's a calculated field based on the Roster field (which has checkboxes entered on separate lines). I used the calculation "Substitute ( Roster ; "¶"; " | " )" for the field and it works perfectly.
I did this because when using the Substitute command on the actual roster field, it broke the checkboxes in the card layout. This is ideal.
Now I'd like to find the best way to populate another name field called RosterFMN, which is the full name of the singer. I don't care if these are on one line or more. I'm going to play with calculations based on the Roster field and see if I can lookup them up from my value list.
the portal TO is gigs_PERFORMANCES. I wasn't using a script parameter at all, but then tried gigs_PERFORMANCES::PerformanceNo=$$PerformanceNo which also didn't work.
In a curious twist, the card/script won't work on the last-entered portal record.
I have three fields to enter on the portal row - songid, set and slot. These, along with the GigID, PerformanceNo and Songname are passed on to global variables. The top fields are globals. The field at the bottom is the actual portal row being edited. This particular record was the last one in the portal, but the record is not actually being pulled into the card. So I I enter three three fields, the cursor is automatically advanced to the next portal record. I see the new portal record created in another open window.
This is the record being edited (Song 042, set 1, slot 20, Performance No 886.
I also have another window open to a table view of the gigs_PERFORMANCES table and see that this portal record above is actually entered.
So I don't understand at all why it isn't working. If click on the button in a different (earlier) portal row, it works fine.
When you didn’t use a ScriptParameter, how tried you the invoked script to let know the context respective the desired target?
"gigs_PERFORMANCES::PerformanceNo=$$PerformanceNo" as ScriptParameter means the script gets only the information if this is true or false – no context – only 1 or 0.
And if you give a ScriptParameter to a script, in the script you have to set a variable with "Get( ScriptParameter )". And then you can tell your script to work with that variable.
In the relationship graph you have allowed creation of new records via this relation. Then in a portal always the last row is an empty row where you can create a new record in the related table by entering values in one of the empty fields.
My suggestion to understand this better would be to take a step back and don't even attempt to open a window yet, so that you don't confuse the result of your newly opened window with how your button on the portal is behaving. They are separate.
If you'd like to learn more about the above, then I'd suggest by starting with having your button just call a simple script that uses Show Custom Dialog to display the value of Get( ScriptParameter ).
Then start feeding in fields from the Portal context as parameters into the Button's script. If the button is indeed contained within the portal, then the data that you see in the custom dialog display will reflect this, and I believe you may see just how elegant and powerful this approach can be.
I suspect that you may have an assumption that opening a new window in your script will automatically take you to the record of the portal row where the button was clicked. That may not be the case. What you can rely on, however, is the ability to receive script parameter values from the portal row, as @Torsten has suggested.
I believe this is what I wanted. Just the record that matches that criteria.
"gigs_PERFORMANCES::PerformanceNo=$$PerformanceNo" as ScriptParameter means the script gets only the information if this is true or false – no context – only 1 or 0.
I have a script called "find performance number" which is set as a script trigger on the card layout and looks like this:
I understand the "empty" record in a portal being there because of the join in the relationship grid. However, when entering a new record in the portal, the fields are populated. This is verified by watching another window open in table view to the same portal. So clicking on the button in the last populated row should pull up that record. No?
At first a reply to your last point with the empty row: Is this new record yet committed? If not then another layout cannot see it. Did you only go on with the TAB key or did you click outside of the portal?
Leaving the last field of the newly via relationship created record does not mean that it is committed. With a click outside of the portal the commit happens. And then the data is really written to the database and other layouts can now see that record.
(Sorry if my English sounds sometimes somewhat strange …)
This makes some sense in that it is not until I click outside the portal that the script works.
However, as I mentioned earlier, I have two database windows open - one with my table and layout and the other with the same layout but in table view. So as I'm entering info in the portal, I can actually see the record being written in the table. This would indicate to me that it is committed, although for some reason, the script seems unable to grab the variable assigned from that record.
I'm embarrassed to say I've never used script parameters. Can you help clarify? I've searched till I'm blue in the face and can't figure out the mechanics of this. My script works in every other instance - just not the most recently entered portal record.
