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

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

Recommended Posts

Posted

Hello there FMP Users.

Has anyone else experienced this? Only after applying the FMP7.0v3 patch (Windows), buttons that perform a script containing a 'Goto related Record' script step do not work. (At least that step does not function - the rest of the script is OK).

I have tested and can confirm that:

a) These scripts worked fine before the patch was applied.

:) Configuring a button with just the Goto Related Record step (as opposed to perfoming a script to do this) works fine, both before and after patching.

c) Installing 7.03a Patch does not resolve this issue.

d) I have also tried creating a brand new test DB (in FMPv7.03a in fact), to try this out and the same thing happens, so it's not due to the fact that this existing DB was created before the patch application process. The scripts I tested contained ONLY the single Goto Related Record step, configured in exactly the same way as the button step which works in :) above.

Any idea on how to resolve this? Can anyone else confirm this behaviour?

Any assistance much appreciated.

Kindest regards,

Richard Coulbeck,

IT Consultant,

University of Otago, Dunedin, New Zealand.

Posted

I haven't seen any other reports of this and the GTRR step works fine here.

If you have FM7 Developer, step through your script to carefully test the context of where you are when the GTRR triggers. Since it works fine from a button but not from a script I suspect you're switching contexts somewhere in your script.

Posted

Hi there - Appreciate the response, but as mentioned:

a) The scripts in question worked just fine before the patch was applied. And it still does when copying the same files back to a PC that has not been updated to 7.0v3. Surely if these was a context problem this wouldn't work in v7.0 either.

:) I have also tested this with a script which has only the one GTRR step in it. So, surely that script couldn't be changing context?

BTW (and apologies) - I should have also included this info:

This is occurring on a DB using a related table in a seperate external file, rather than another table in the same file. Thus the step in the script, (and/or the Standard GTRR Button that does work), and is using the 'Use External Table's Layout' option checked with one of the layouts in that file selected. It is also using the 'Show only related records' option.

I haven't yet tested this using a related table in the same file under v7.03a - it may well work, but I'd much prefer to have these tables in seperate files if possible.

Regards,

Richard.

Posted

I suspect you're switching contexts somewhere in your script.

Yes GTRR needs to follow TO's related to each other, and not a TO from the same table without a defined relationship!

--sd

Posted

Relationships are defined in both directions, and the problem occurs in both directions - again only after patching to v7.03. ie Try this:

1 - Create File1/Table1: with LinkField + a few others.

2 - Create File2:Table2: with Linkfield + others.

3 - Define Relationship in T1 to T2 using Link Field, allowing record creation.

4 - Add portal to Layout in T1 to view multiple records from T2

5 - Add a button in Portal Row with GTRR Step

6 - Add a new record to T2 using portal by adding at least 1 fields data.

Button works fine as expected.

7 - Create a script with single GTRR step as described in previous post.

8 - Modify same button to instead Perform that script.

This does not work for me?! I can confirm that I can switch to T2 window using Window menu, and T2 is in Browse mode - should be fine.

Same occurs in reverse direction (ie from T2) - and yes of course the Relationship needs to be defined from T2 as well for that to work.

Does that make sense?

Posted

This is occurring on a DB using a related table in a seperate external file, rather than another table in the same file.

Ah! Guess what the function of the checkbox in the GTRR def. called "Use external tables layouts" does???

--sd

Posted

Thanks SD - Ok - I'll show my ignorance? Sorry, I didn't quite follow your reply. My understanding was that that option displays the related records using the Layout you specify in the external file - exactly what I want it to do, and what it's doing on my machine here at home right now, which I haven't patched yet.

Cheers,

Rich.

Posted

Well while buttons that uses single line commands gives an error message if you attempt to do a GTRR without the checkbox checked, isn't any warnings given if you have put the GTRR somwhere in a script, it simply continues as if the GTRR wasn't there at all.

--sd

Posted

To clarify - you did see my post above where I explained I was indeed using the 'Use External Tables Layouts' option in the test GTRR script step, right?

Sorry no I didn't ....then must it be a flaw in the logic where you're using the wrong TO via a layout tied to another TO than the graph needs. What does the Layout Setup say the TO is??

--sd

Posted

Hi there.

I do appreciate the input. It's quite true that you can use that extra 'Select Window' step, and my actual solution has already applied that, but it was what I was calling a 'work-around'. The demo script was a single step only to clearly demonstrate what I still thought was 'incorrect' behaviour in the GTRR step, which has occurred ONLY since the 7.03 patch was applied. I haven't seen any documentation from FMP regarding this change in behaviour, and the documentation in FMP itself still doesn't suggest that the extra step should be needed (in my opinion). However, it is true that there is a solution as you have kindly shown, and it's a pretty easy one, and so maybe I should just have left it at that. Interested though - you obviously confirm the behaviour I described in the demo - is this correct? I have emailed FMP online about this twice, and never received a reply back from them, so well done and thanks for being so responsive in this forum!

Cheers,

Richard.

Posted

It's a pity you didn't say you had a solution - it took me a while to find it. On the bright side, finding it helped me to understand the logic behind it.

I don't think this is a workaround. Actually, it's pretty smart this way. As it happens, I have a perfect example to show why this is necessary:

I have a script that goes to a related record and deletes it (I cannot delete the portal row, because the related record is sourced from a third table). If the Select Window step were to be incorporated into GTRR (as seems to be the case with a dedicated button), I would be getting a nasty flash (Freeze Window obviously will not freeze other windows). And I still would have the burden of closing the window in order to return to my point of origin.

So instead of complaining why the SCRIPT STEP 'Go to Related Record' does NOT include a 'Select Window', you should be thankful that the SINGLE ACTION does (it wouldn't be very useful in your situation without it). Seems to me you're getting the best of both worlds: ultimate control in a script, and a convenient combo shortcut in a dedicated button.

---

Note to FMI, Inc.:) I should be paid for this, I think.

Posted

To 'Comment' - I do humbly apologise for not making it more clear that my question was more about the fact that it's behaviour seemed to have changed without warning in 7.03. I thought that was what I was asking about, but I should have realised there would be kind folks out there like yourselves that would be solving it for me, by coming up with alternatives. This was my first post to this forum, and I'll know better next time!

I'll admit to you that I had only found that solution myself somewhat by accident when discovering that when switching windows manually (from the menu) after testing that script step, the correct record was being displayed (and the found set was correct), so clearly a subsequent 'switch window' would do the trick.

Of course, the GTRR script step in earlier versions of FMP switched windows itself, but I guess on reflection the change in design (if it really is that?) may well be related to the fact that FMP7 allows multiple windows to the same DB table open? So which one do you switch to then? Thus I can accept that this behaviour is perhaps by design - however, you'd think it would have behaved that way before the 7.03 patch then?

It was this all along that was by real query and 'complaint'. i.e To see if anyone else was seeing that same behaviour, or whether something else was going on just for me. The rest of the 'discussion' and the demo ended up being more about proving what I was saying was true, as for a while there I think I wasn't being believed - fair enough though. :-)

In addition, this could have the potential to break alot of databases, that get upgraded to v7, if FMI didn't add that extra step automatically during the upgrade - and that's a bad thing in my opinion.

Once again - thanks again, and I really do appreciate the significant effort you all went to on my behalf.

Cheers,

Richard.

Posted

And I should have added that I found that alternative shortly AFTER my first post, but was still thinking there might be a known issue with the step itself - so the ongoing discussion was worthwhile for me, and I hope for others. I also still think it's an issue that FMI should be aware of, (and maybe I should be paid for that)? he he

--

Richard.

Posted

I'd think a patch is SUPPOSED to change the way an application behaves. If I understand correctly, you could not GTRR in "stealth" mode before applying the patch, so I would consider that a much needed improvement.

AFAIK, a lot of solutions do break when brought over to version 7, on a variety of issues. The change in the basic paradigm is quite drastic - just see the extent of the migration white papers on FMI's site, and the amount of posts in the Migration section here.

This topic is 6943 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.