Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 7338 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

Edit: I need to clarify the original question. I'm asking about the change to the behavior of the Go To Related Record script step. In previous versions, it did not bring the related file to the foreground. In version 7, it does. I need to have the functionality of this step without bringing the hidden related file to the foreground. Is there a way to do this in 7, or has this functionality disappeared, to be replaced with a complicated workaround?

Original post:

I have a 13-file database written in 5.5 and I'm currently going through the process of converting it to 7. So far so good, I've figured out several issues so far but I've encountered one I'm stumped by.

In the old version, I often used the Go To Related Record script step to specify the active record in a related file before calling a script in that file which acts on the active record. These related files were usually data files that were kept hidden at all times. Now, after converting to 7, whenever a script uses a Go To Related Record script step, it shows the hidden related file. I tried unchecking "Use External Table's Layouts" but now the script step just fails with the error "This operation could not be completed because this layout cannot display the result."

I always thought Go To Related Record was a standard way to specify the active record in a related file, which is clearly something you often need to do, whether or not you want to bring that file to the foreground. But now I can't find any obvious way to do that.

Does anyone know if there's a canonical solution to this particular changed behavior?

Thanks very much!

Posted

Change to a layout that refereneces the related table occurrance.

Posted

More explicitly, go to a layout which uses records from the appropriate TO. You can check what TO a layout is based on by going to Layouts -> Layout Setup, while in Layout Mode, of course.

Posted

I don't want to go to any layout! These scripts are running big messy calculations that involve scanning through thousands of records; some of them take five minutes or more to run. The only purpose of the Go To Related Record script step in these scripts is to set the active record in the faceless related file, so that the subroutine script in the related file will know what record to act on.

In previous versions of filemaker, Go To Related Record in another file will only bring that file to the foreground if it's the last script step in a script. In the middle of a script, it does exactly what I was using it for: sets the active record in the related file, without doing anything else at all.

What I'm wondering is, is there still a simple, reasonable way, in 7, to set the active record in a related file, without needing to worry about layouts? This was a pretty useful aspect of Go To Related Record before!

-dave

Posted

You can't Go to Related Record if the current layout is not based on a TO that is the left-hand key for the relationship. In other words, if you're on a Clients layout, you can't Go to Related Records that are based on a relationship from Projects to Invoices. You have to go to a Projects-based layout first.

You can Go to Related Record, with the appropriate external layout specified, and then Maximize Window. If there is only one related record, then you don't need to go to it anyway, unless you want to perform additional steps in the related file. You can access it by using relationship::field instead.

Posted

I have the same issue as dave. I use "go to related record" step as a "one step" find. I also do not want to go to another layout. This is done behind the scenes.

If Fm has change this I will have to create a much more complex way of finding related records. I know before I discoverd the "go to " step I copy'd the job number then ran a subscript that went to find mode, pasted job number the performed find. But that is many more steps. Maybe this can be done by passing script parameters. I havent yet tried that one.

Posted

Due to the new multiple tables per file ability, it makes sense that it would complicate the GTRR step. It isn't as simple as going to a related file. It depends on what layout you're on and what layout you want to end up in to display the related records. It's easy enough to add an additional step to come back to the calling file afterward. But what's the point of finding related records if you're not going to do anything with them? You can change the first and last related records' values via relationship without going to them, and you can view the related records in a portal. The only reason to move to the records is if you're looping through them for some reason or want to run a Relookup. In either case, you would still need to specify what layout to view them in.

Have you tried freezing the window before you GTRR, doing your thing, and then Commit Records/Request from the parent file to save your changes to the related records and make the parent file active?

Posted

Let me clarify again. The Go To Related Record script step does work. It worked fine in 5.5, and it works fine now. The script generates the correct results, the numbers all match up, everything is fine. The only thing that has changed is that now every Go To Related Record script step brings the related file to the foreground. In previous versions of Filemaker, the Go To Related Record script step did not bring the related file to the foreground. I am asking if there is any way to duplicate this functionality that used to be available.

I don't know what TO stands for, but I assume you're talking about the "Display records from:" setting in Layout Setup. There's only one table in each of my files, not counting the relationships, because this whole thing was just converted from 5.5. The "Display records from:" is set to the file itself; as far as I can tell, every layout in every file is set that way automatically during the conversion process. But I don't want to get bogged down in the details of this aspect of the database, because as I said, the only thing I'm asking about is files being brought to the foreground.

These Go To Related Record script steps are being run from appropriate layouts, with portals, or some such. Different in different cases. As I said, they all work, they just un-hide my hidden windows.

Posted

Here's a simple solution. Create a new layout in the main file based on the related TO in the other file. It can be blank or you can put related fields on it. Set your GTRR step to use this layout. Then Go to Layout [original] to return. If you want to loop through related records without opening the related file, this will work also.

Posted

The only reason to move to the records is if you're looping through them for some reason or want to run a Relookup. In either case, you would still need to specify what layout to view them in.

That is exactly what I am doing: looping through them. I am looping through them invisibly, in the background, because I needed to do various calculations on them that couldn't be done any other way. Since it's invisible, in the background, I don't care about layouts at all. (Except for the starting layout, which has a portal to select a related record, which is the related record that I'm starting the loop at in the related file.)

Have you tried freezing the window before you GTRR, doing your thing, and then Commit Records/Request from the parent file to save your changes to the related records and make the parent file active?

Yes, I always freeze window at the beginning of any of these scripts that do these scans. I did some experiments and the presence or absence of the Freeze Window step makes no difference in whether the hidden window becomes visible.

Surely it's not that unusual to want to just set the active record in another file, even if you don't want to navigate to that file?

Posted

Here's a simple solution. Create a new layout in the main file based on the related TO in the other file. It can be blank or you can put related fields on it. Set your GTRR step to use this layout. Then Go to Layout [original] to return. If you want to loop through related records without opening the related file, this will work also.

That makes sense. Kind of an ugly kluge, but it's certainly easier than reworking it to avoid the GTRR script step altogether! I'll try that tomorrow and post if I have success!

Posted

Worked like a charm. Thanks, Queue!

One weird thing: after I changed the Show record using layout: to the newly-created dummy layout, it still shows up as <unknown> in ScriptMaker... guess there are still a few bugs in 7...

I've attached a screenshot.

scriptanomaly.jpg

Posted

Yes, I believe this is a bug that has been discussed before. It still works though, and that's what matters.

  • 2 weeks later...
Posted

Oops, I spoke too soon; I hope someone authoritative is still reading this thread!

After I set the GTRR step in the main file to use the new dummy layout, the GTRR step no longer sets the active record in the related file. So, this actually is a much worse situation than before, because now my scripts don't work at all, rather than working with flashing windows.

So, once again, does anyone know if the ability to set the active record in a hidden file without un-hiding it has simply been removed altogether in verion 7?

-dave

Posted

Well, it should never set value of an active record unless it is the first related record, if by active you mean in the related file's/table's current found set.

Check the change log for v3. They've changed the functionality of GTRR so that it doesn't open the related window unless called via button step.

Posted

I relate to your frustration. Here's a possible remedy. Go to the help file in both 5.5 and 7 and search on "Go to related record" and compare carefully. I find that the answer is usually staring me in the face if I slow down and read it like it is the first time I've ever seen it.

I wonder if a simple set field or find will suffice given the new way 7 does things.

Posted

Dave, I may have found your answer! Thanks to "ender" who suggested a solution to one of my problems was a fix in V 7.03. While reading about the changes, I came across this feature which sounds like it addresses your problem. (I have attached the complete pdf for anyone who has strange migration problemss and is pulling their hair out like I was. You might find your answer there)

This is from the read.me pdf file that comes with the 7.03 download....

1.4.1. In order to be consistent with other script steps and with previous versions of FileMaker Pro, the Go to Related Record script step no longer brings the related window to the front automatically, except when used from a button. In order to bring the related window to the front, you must add a Select Window step to the sc1.4.1. In order to be consistent with other script steps and with previous versions of FileMaker Pro, the Go to Related Record script step no longer brings the related window to the front automatically, except when used from a button. In order to bring the related window to the front, you must add a Select Window step to the script.

This topic is 7338 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

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