Running a simple populating script by you

[fmow]

Can I just run this by you guys to tell me what you think. I need a few more experienced eyes to catch any mistakes here, since this will be the backbone for a lot of operations in my db.

 

Set Variable [ $Var; Value: Get ( ActiveFieldContents ) ]

Go to Layout [ “‘Clients” (Clients) ]

Perform Find [ Specified Find Requests: Find Records; Criteria: Clients::NameSurname “=$Var” ] [ Restore ]

Set Variable [ $Var2; Value:Clkients::_pk_Client_List_Serial_Number ]

Go to Layout [ original layout ]

Set Field [ Projects::__fkClientID; Projects::__fkClientID=$Var2 ]

Commit Records/Requests

Exit Script [ ]

 

So basically I am in the Projects layout, grabbing a Client name inputted via predefined value list based on the available clients in the table, finding it in the clients table, then going back and pasting this id in the Projects layout. 

 

This is for a simple case not the case of a joint table, which maybe I ‘ll post later. 

 

Is this good practice? I want to start, so to speak, on the right foot here in terms of good practice. 

[jbante]

Have you tested it? Does it work? Anything you can learn from testing trumps what any of us can tell you. If you test it and it works, who's in a position to argue with results? That said, there are a few things I would do differently if I were writing this, mostly matters of style.

 

Your script does not account for the highly plausible error where the find has no results. Try something like this to "capture" the error and prevent the script from making things worse if something goes wrong:

 

...

Set Error Capture [On]

Perform Find []

Set Variable [$error; Value:Get ( LastError )]

Set Error Capture [Off]

If [$error ≠ 0]

Go to Layout [Original Layout]

Show Custom Dialog ["Error: " & $error]

Exit Script []

End If

...

 

This particular error capture pattern, aborting the script in the middle if something is wrong, is called a guard clause. There are a few reasons why I like this approach, but there are other perfectly reasonable ways to do this, too.

 

You're specifying your find criteria in the Perform Find script step itself. Though your presentation of it here allows us to see what the find criteria are, it doesn't actually show the criteria when reading the script unless you open the options for the script step, which is a hassle for the next developer who has to maintain your code (and for you after you've forgotten what you were thinking). (Even if the script did show you all the find criteria, it would have to truncate the view of the several criteria in a complicated find.) So I always do this:

 

Enter Find Mode []

Go to Layout [...]

Set Field [...]

Set Field [...]

Set Error Capture [On]

Perform Find []

Set Variable [$error; Value:Get ( LastError )]

Set Error Capture [Off]

 

I do this so often, I have it saved as a snippet I can quickly paste into any script I'm working on. Doing it this way, it's easier to read the find criteria in each of the Set Field steps without having to open the Perform Find options dialog.

 

Also notice that I enter find mode before switching to the layout I'm performing the find on. This way, when you load the layout, you won't also be loading any records or calculating any summaries from the table (occurrence) that layout is based on until you've got the record(s) you're actually interested in, so the script may run a little faster.

 

Try getting in the habit of using more meaningful variable names. In a short script like this, it's easy enough to see where $Var and $Var2 came from, but it's very helpful when writing longer scripts or maintaining scripts to see what the developer was thinking when they wrote the script as expressed by variable names:

 

Set Variable [$clientSurname; Value:Get ( ActiveFieldContents )]

...

Set Field [Client::nameSurname; Value:$clientSurname]

...

Set Variable [$id_Client; Value:Client::id]

...

Set Field [Project::id_Client; Value:$id_Client]

[fmow]

Have you tested it? Does it work? Anything you can learn from testing trumps what any of us can tell you. If you test it and it works, who's in a position to argue with results? That said, there are a few things I would do differently if I were writing this, mostly matters of style.

Your script does not account for the highly plausible error where the find has no results. Try something like this to "capture" the error and prevent the script from making things worse if something goes wrong:

 

...

Set Error Capture [On]

Perform Find []

Set Variable [$error; Value:Get ( LastError )]

Set Error Capture [Off]

If [$error ≠ 0]

Go to Layout [Original Layout]

Show Custom Dialog ["Error: " & $error]

Exit Script []

End If

...

This particular error capture pattern, aborting the script in the middle if something is wrong, is called a guard clause. There are a few reasons why I like this approach, but there are other perfectly reasonable ways to do this, too.

 

You're specifying your find criteria in the Perform Find script step itself. Though your presentation of it here allows us to see what the find criteria are, it doesn't actually show the criteria when reading the script unless you open the options for the script step, which is a hassle for the next developer who has to maintain your code (and for you after you've forgotten what you were thinking). (Even if the script did show you all the find criteria, it would have to truncate the view of the several criteria in a complicated find.) So I always do this:

 

Enter Find Mode []

Go to Layout [...]

Set Field [...]

Set Field [...]

Set Error Capture [On]

Perform Find []

Set Variable [$error; Value:Get ( LastError )]

Set Error Capture [Off]

 

I do this so often, I have it saved as a snippet I can quickly paste into any script I'm working on. Doing it this way, it's easier to read the find criteria in each of the Set Field steps without having to open the Perform Find options dialog.

Also notice that I enter find mode before switching to the layout I'm performing the find on. This way, when you load the layout, you won't also be loading any records or calculating any summaries from the table (occurrence) that layout is based on until you've got the record(s) you're actually interested in, so the script may run a little faster.

Try getting in the habit of using more meaningful variable names. In a short script like this, it's easy enough to see where $Var and $Var2 came from, but it's very helpful when writing longer scripts or maintaining scripts to see what the developer was thinking when they wrote the script as expressed by variable names:

 

Set Variable [$clientSurname; Value:Get ( ActiveFieldContents )]

...

Set Field [Client::nameSurname; Value:$clientSurname]

...

Set Variable [$id_Client; Value:Client::id]

...

Set Field [Project::id_Client; Value:$id_Client]

 

 

[Lee Smith]

I’m not going to help with this script, you are already getting help from one of our stars.  but if you are going to do much developing, then you should consider upgrading your application to the Advance edition where you can test your own scripts.

[qube99]

You mention pasting code snippets. Do you save the snippet as a script or as a custom function? I have a separate database I call "Cheats" where I store all sorts of solutions and code stored as scripts. I link it to each project so it's immediately available, visible by dev only. How do you handle yours?

 

You provided several great ideas that make me want to go back and tweak a few of my projects.

 

Thanks!

[jbante]

fmow, I like the default error capture state in a script to always be off — turning it on is the exception for me. Leaving error capture on can mask problems that I would quickly be alerted to otherwise. If there's an error I haven't accounted for, I want to see the alert dialogs telling me so, and so I turn Set Error Capture off when I'm done trapping a known plausible source of errors.

 

If your users are already selecting a Client surname via a value list, why don't you get the Client ID from the same value list (using 2-field value list, only showing the surname field) and bypass this particular script altogether? Then you can just put a pop-up menu on the Project::id_Client field on the first layout and be done with it.

 

qube, for the particular example I was talking about, I don't store the snippet as a script or a custom function. I copied the script steps to the clipboard and saved the snippet in Clip Manager, where I also store all my other snippets that aren't plain text (script steps, fields, layout elements, etc.). All my plain text snippets (calculations and common comment formats) are in TextExpander.

[LaRetta]

Oh!  I forgot that, now that I'm primary Mac with Windows secondary (instead of other way around) that I can use TextExpander that I've heard so much about over the years!  Thanks for the reminder, Jeremy!  Clip Manager rocks also.

[jbante]

Oh!  I forgot that, now that I'm primary Mac with Windows secondary (instead of other way around) that I can use TextExpander that I've heard so much about over the years!  Thanks for the reminder, Jeremy!  Clip Manager rocks also.

 

When I have to develop on both Mac and Windows, I use Breevy on the Windows side. It does the same job, and it can sync with TextExpander via DropBox.

[LaRetta]

Sooooo much to learn and so little time but that is what I love - I am never bored in this business.  Each tool I take the time to incorporate in my daily work usually returns more time exponentially so ...

 

very poor sentence but it said exactly what I wanted to say.  Thank you!

 

ps  my Windows box is XP :-/  so I will be upgrading it very soon.  Never bored indeed!  And my Mac is in a box on journey to see AppleCare in the morning so I am feeling a bit like a lost puppy tonight.  <-- puppy