Copy Paste Right and Wrong

[cathyka]

I seem to be using copy and paste a bunch in my scripts. Mainly to link records across layouts using different tables and sometimes from portal to portal in other layouts.

I recall reading somewhere that copy and paste is common mistake made by a newbie like me. I have tried using Set Field but that does not work in many of my senarios.

What is my best choice for getting text from one field in one table to different field in another table? And while I am at it.... What are the most common and most hurtful mistakes I could make when scripting?

Thanks!

[MoonShadow]

Oh I must answer this one ...

What are the most common and most hurtful mistakes I could make when scripting? "

Error 1: Set User Abort [ Off ] and then get yourself stuck in a never-ending loop. Never turn User Abort off until you're sure your scripts are perfect. First-hand multiple experience here.

Error 2: What to do with End Ifs. They can drive you nuts if you get a complex script going and you keep getting an error. List out and visualize each movement your script needs to make. Split each part of a script into small group actions and test them. Use Debugger if possible to watch them in action. Then write them together into one script. Before long you'll be typing them from memory and visualizing them in your head as you do.

Error 3: Not protecting Users from dangerous things such as Delete All Records, Replace Contents or other mass data-overwrite activities. Protect them, give them clear options out, back up the data for them behind the scenes even if they confirm they know what they're doing.

Error 4 (not asked for but offered anyway because it's probably the #1 newbie error: Using flat-file structure. Any time you find yourself creating more than one field which is the same, ie, Vehicle 1, Vehicle 2 etc ... consider seriously splitting it into its own file/table. It's not always necessary to split but if you split it's always easy to put back together. When in doubt, split it out.

Copy/Paste can (and should) usually be replaced with Set Field, Script Parameters or globals. Until you get the hang of which would be best to use in each situation, you can always post here and get help.

[Søren Dyhr]

What is my best choice for getting text from one field in one table to different field in another table? And while I am at it.... What are the most common and most hurtful mistakes I could make when scripting?

Set field[ is usually the best bet, and the reason for it is that the exploit of the operating systems clipboard which is ment for interapplicational exchange, could harm say a image or a soundsnip, if your filemaker app runs at the same time as you gets your holiday snappies sorted. Alright better examples exists??

However will it perhaps make sence to get you specific problems solved. Why is it Set Field[ doesn't work in your case??? Even if tables not are related will scriptparamters and globals be abel to store issues similar to Copy and Paste.

Now scriptparamters are usually attached to a button but can also be passed when a script calls a subscript, and very conveniently are outer parameters stacked if say you're calling yet another subscript inside a script using it's own paramters.

This haven't been posible before in filemaker, but pretty commom in Object Oriented Development ...this is why a thread like this came up a few month ago: http://www.fmforums.com/threads/showflat.php?Cat=0&Number=151042&an=0&page=0#151042 - Even though recursions in scripts have been banned earlier on, could a simple recursion in scripts now be utilized just to pluck a parameter for the same script, without attaching it to a button.

Since 4.0 but especialy after 5.0 has ValueListItems( solved a lot of issues that earlier called out for the use of Copy All Records[ in a technique which is called dwindling take a look at the templates here:

http://www.kevinfrank.com/demo_files.html

But they're bygones as well, there's no particular reason any more with the multitude of options in relation types such as < or > or unequal as well as the ability to recursive definitions in Custom Functions.

--sd

[cathyka]

Ok, I haven't really been able to grasp the proper use of global fields. And script parameters well....don't know much about how to apply those either... maybe you could help me understand, here are a few of my senarios...

Table to Table

Table Specs has SpecID. Specs need to be Estimated by various vendors. Specs are related to Estimates Table via SpecID = SpecID. I have a button on specs that

Copy Spec ID > Go Layout Estitmates > Paste Spec ID...

Portal to Portal

Items Table has two portals. Print Specs and Package Specs. I need to select from the list the Print Spec ID and Print Titles that belong in the Package. Currently I have made the Print Titles field a button.

Copy Print Spec ID (print specs portal) > Go to Portal Last > Paste Print Spec Id (package spec portal)

Could you help me understand how I could do this using global or script parameters?

Thanks!

[Søren Dyhr]

I'm unable to understand the first scenario - could you please expand?

Portal to Portal

Items Table has two portals. Print Specs and Package Specs. I need to select from the list the Print Spec ID and Print Titles that belong in the Package. Currently I have made the Print Titles field a button.

Copy Print Spec ID (print specs portal) > Go to Portal Last > Paste Print Spec Id (package spec portal)

Even-though it's not really a normalized structure, could it be done the way I demonstrate it in the attachment, the issue is that the process is the same when it comes to handling key values.

The whole issue with relational database structure is to solve updating issues between tables, by letting data stay as atomic as possible in one place, and then make it be shown only by reference if elsewhere desired.

This means that if your lines just are different views of the same record, does it make more sense to make the record show up in the other portal simply by either adding it's ID to a return-delimited list that act as key ...or make the records key be "copied" via Set Field[ to another foreign key-field in the same record, so the same record shows up in both portals if needed.

--sd

cathyka.zip

[cathyka]

Brillant. Seem like that will work well. (But I still don't understand what the script parameter accomplishes.

ValueCount ( Get ( ScriptParameter ) ) = 2

And to address the normalized structure, my thinking may be incorrect. But this is what my goals are.

Print Specs remain constant. (except for quantity).

Fulfillment Specs remain constant. ( except for quantity).

I am selecting Print Specs to add to Fulfillment Specs to create Packages. That is where the Items table comes in it links the quantity to the print spec and Fulfillment specs. The Print specs will be Estimated (by various vendors) and the Fulfillment Specs will be Estimated (by various vendors.) An estimate will be chosen for each Print Spec linked to the Fulfillment Spec to create a per item cost.

The Per Item cost will be multiplied by the Quantity to create the total costs for the packages. This information is calculated and stored in the Fulfillment Specs. These cost will then be used for Pricing.

Print Orders will be created from the Fulfillment Specs. Quantities will change regularly. But the print specs will remain constant. As will the Fulfillment Specs. Am I approaching this in a typical novice fashion?

Thank you so much for all your thoughts. It is extremely helpful.

cka

[cathyka]

Oh My.... the script parameters just clicked! Thank you! I can see the value and all the script fixing I need to do!

[Søren Dyhr]

I am selecting Print Specs to add to Fulfillment Specs to create Packages. That is where the Items table comes in it links the quantity to the print spec and Fulfillment specs. The Print specs will be Estimated (by various vendors) and the Fulfillment Specs will be Estimated (by various vendors.) An estimate will be chosen for each Print Spec linked to the Fulfillment Spec to create a per item cost.

This does indeed suggest that it's the same record, since the price is supposed to be a lookup, mirroring the specific price at the time the offer was given ...otherwise will you in a turbulent era experiences that printed prices not are identical with the offered prices - if say the price depends on day 2 day prices or occasional alterations of prices.

But take a look at a more normalized version of the issues mentioned...

--sd

cathyka2.zip

[cathyka]

Thanks SD!