Problem with scripts and tabs

[aliquis]

I have a form layout that uses 4 tabs, with some fields common to each tab. I want to use a script that involves copying the content of a field, but whenever I use the Copy script command it changes the tab selected and copies from the version of the field that is on that tab, rather than the tab that is already selected before the script starts. The tab that it goes to is not even the default tab for the layout.

I have created a brand new script consisting only of the Copy command, and it still does this. I can't understand why. Can anyone help please?

[mr_vodka]

Since you are using 8.5 you can label each tab with an object name. Then in your script, store the current tab tab that you were on in a global variable or field. Next set varibles to the values you want to copy, go to the new tab (object name) that you want to copy the field data into and then use set field.

Try to stay away from copy and paste. There is no reason to litter your user's clipboard.

Also saying that you have all these common fields brings up a small flag with me. Care to explain your situation?

[Søren Dyhr]

Before getting any deeper are there are several issues here, why copy in the first place?

Why are there several versions of the same field?

--sd

[mr_vodka]

:

[aliquis]

[color:black]Thanks for your very quick replies. OK - an explanation. The common field is a code identifier for the entity stored in the record. The 4 different tabs record different sets of fields and the code identifier is of course common to all of them. The script is to enable a search for all other records that have the same two first digits as the code identifier for the record in question.

You are right, of course, that copying is an inelegant way of doing it. I have altered the script to eliminate it, and it now goes:

set a variable from the first two digits of the code;

go to find mode;

insert calculated result, where the calculated result is the variable;

perform find.

The problem is that it now does exactly the same thing when I insert the calculated result. It's as though there is a hidden tab selection when you select the field to insert in.

I realise I could get round it by storing the tab object name at the beginning and then reverting to that at the end. But that too is rather inelegant and I suspected that there is something obvious I am missing that is forcing the tab change in the first place that I might be able to avoid.

I have replicated this in the attachment. When you run the script from any tab it will always revert to Tab 1.[color:black]

Test.fp7.zip

[aliquis]

I think I've just cracked this myself. If I do as you suggested, Mr Vodka, and use set field instead of insert calculated result or paste, it doesn't switch tabs. So problem solved - many thanks.

But I'm still curious to know what's going on when the tabs switch using the other commands.

[mr_vodka]

The tabs are lets say like "layers". If you open a file which has tabs in it, in FM7 where tabs are not supported, you will see that the fields are all on top of each other.

So if you have the same field in each tab, when you insert calculated result, paste, etc. into a specific field, it will default to the first instance of the field and insert it there, thus switching your tabs.

I still have questions about your structure though. Are these fields from three Seperate related tables or from one?

[aldipalo]

Instead of putting your ::code on each tab why not put the ::code outside of the tab area? If all fields in all tabs are related to the same record you will accomplish the same result.

I've added to your file showing this approach as well as using related files. (See attached file and go to "New Layout")

If the original method is preferred, the script , with object names, runs very quickly so you can get the data from any Tab you choose.

So, what exactly is the problem? I guess I am missing something.

Test_Object_Script.zip

[aliquis]

Thanks for your suggestions.

To answer your questions:

The fields are all from one table. In fact the structure is identical to the example I posted. Yes your explanation makes sense Mr Vodka - I hadn't thought of it in that way. But if it defaults to the first instance of the field when copying, pasting or inserting, I wonder why it doesn't do that with the set field command.

It does seem an obvious answer from a practical point of view to set the field outside the tabs; the reason for not doing this is purely aesthetic given the layouts I've constructed. The problem I had was being able to run the script from within whichever tab I started from, without the tabs changing along the way. There are a number of work-arounds but I really wanted to understand what was happening.

Thanks again for your help.

[mr_vodka]

I wonder why it doesn't do that with the set field command.

The set field command does not require the field to be on the layout, so its does not "go" to a particular field.

[Søren Dyhr]

All right it seems to be solved, although I indeed have been wondering severly what the real purpose would have been. My thoughts went around splaying the first 3 of a found set on each their own tab, such as the SQL command TOP 3.

If that was the case, could it be solved by a relation, and a cut up one line of a portalrow shown in each it's own tab - to gather the ID's of the first 3 records in the found set, have GetNth( proved to be a good feature for that purpose, provided you keep yourself from stuffing it inside a List( statement....

--sd

fff.zip

[aliquis]

Thanks Mr Vodka - didn't realise that about the set field command. Guess that's why I'm still a novice.

Thanks too for your script Søren Dyhr. Never done SQL either. Another reason for being a novice...