Passing ScriptParams into a HelpRequest

[tonywhitelive]

Many years ago (pre FM 16) we built a Help Request system including a dedicated (HelpRequest.fmp12 File) that we call from multiple files, passing in a dictionary of name value pairs based on Get ( Functions ), a few Design Functions, and a script comment (polyfill).

Pre FM 16, we used (Six Friend Rice) SFR to build the dictionary. We did not use a Custom Function (CF) to wrap the dictionary (in order to make the code more portable). Probably should have committed to using a custom function.

We distributed the code based on Scope (Script, File_Layout, or Application/Session) between the calling Scripts, a few Scripts local to the file, and a few Scripts in the HelpRequest File.

We are in the planning stage of refactoring the code to:

• Switch from SFR to JSON
• DRY out the code by using a CF in the calling Scripts
• Possibly adding or removing some of the values gathered in the calling Script.

Because we have some customers still on FMS 18, the plan is to use the features up to FM 16, which should be both safe and sufficiently helpful. Because we are DRYing out code into Custom Functions, moving up to higher versions will be relatively easy.

Below is the "before" Custom Function done, as you can see, using SFR. We are going to update the name of the fields where the Function name has changed.

Please note that "scriptID" is a CF. Should it be renamed to @scriptID? Vote!

Question 1: What would you name this function?

• scriptParams or @scriptParams?
• helpRequestParam or @helpRequestParam?
• Other?

Question 2: Are there any values with Script scope that you would add to the CF?

As for passing the param (name value pairs) into the HelpRequest, do you prefer Method #1 (line 42) or method #2 (lines 45-46)?
(we would of course use only one)

People might also want to look at this related post and comments...

Get All Get Functions

Good topic, post, and replies.. Timely, as we are using a pre-pre-FM 16 version that is on the To Do list for a modernization. We use this type of Calculation/Custom Function as part of our HelpRequest system. Currently we "Get" info from 3 scopes: Script, File&Layout, and Environment/Install passing them along the ScriptStack and writing them out to fields in a HelpRequest record. We also add some items: Script Comment @scriptID @layoutID DatabaseNames WindowNames etc. Might (or might not…

Thoughts?

[Malcolm]

Using @ as a prefix for CFs leaves me cold. I prefer cf_FunctionName. Type ahead will pick that up with “cfn”. Type ahead with @ is going to be a pain.

@tonywhitelive

As for passing the param (name value pairs) into the HelpRequest, do you prefer Method #1 (line 42) or method #2 (lines 45-46)?

The disadvantage of declaring the parameters in a variable outside the script call is that it might lead developers to think that the variable is needed elsewhere when they are modifying the code. They may leave it behind.

[bdbd]

I think you are losing an opportunity by using the @ character at the start of a function name. I use a prefix that acts as a name space. This groups my scripts. My name space convention first groups by publisher (two or three characters), then by "object". This makes it fairly quick and easy to limit type ahead results with a few characters.

As for passing parameters, I would prefer method 2 in this case. Your custom function returns a fair amount of information. Method 1 would require you to enter the subscript to see this information in the debugger. Method 2 allows you to see this before invoking the subscript.

[steve_ssh]

@bdbd

I use a prefix that acts as a name space. This groups my scripts.

+1 for liking name-spacing of CF's

@bdbd

As for passing parameters, I would prefer method 2 in this case. Your custom function returns a fair amount of information. Method 1 would require you to enter the subscript to see this information in the debugger. Method 2 allows you to see this before invoking the subscript.

+1 to really liking declaring the param in the variable to assist with debugging. But I don't do this with all my scripts. In particular, my validation + error logging scripts are often implemented as one-liners so that I can stack a sequence of them in what (subjectively speaking) feels like a tidy fashion.

Question 2: Are there any values with Script scope that you would add to the CF?

I usually also capture FoundCount and LayoutName or LayoutTableName. Understood that, strictly speaking, these are not limited to script scope, so you may already be capturing them in the HelpRequest script being invoked. That would certainly make sense to me -- I'm just used to capturing these at the CF level.

[tonywhitelive]

@bdbd

I think you are losing an opportunity by using the @ character at the start of a function name. I use a prefix that acts as a name space. This groups my scripts. My name space convention first groups by publisher (two or three characters), then by "object". This makes it fairly quick and easy to limit type ahead results with a few characters.pt.

Name spacing Custom Function (CF) suites, for example...

• value.* // value.index.ci ; value.last ; etc
• format.*
• parse.*
• escape_for_*
• readability wrappers
• filter.*
• SFR
• JSON
• others?

...is useful. Whether there is a @ before the suite name is a lively debate!

[tonywhitelive]

@steve_ssh

I usually also capture FoundCount and LayoutName or LayoutTableName. Understood that, strictly speaking, these are not limited to script scope, so you may already be capturing them in the HelpRequest script being invoked. That would certainly make sense to me -- I'm just used to capturing these at the CF level.

Yes, the Perform Script that reports an error in a Script calls a Script in the File that picks up FoundCount, LayoutName, LayoutTableName, etc.

That Script is also called from other places (with Screen Capture and/or Snapshot Link) so we keep to the scope so that we are DRY.

Might also be .00000001 seconds faster

[tonywhitelive]

Time to vote again... 1, 2, 3, or 4 (and why, for extra awesome)

Here is @helpParam

[Malcolm]

# 2 is tidy, readable, and supports branched logic.

if ....
Set Variable[ $scriptComment ; "x" ]
else if ...
Set Variable[ $scriptComment ; "y" ]
else 
Set Variable[ $scriptComment ; "z" ]
end if

Perform Script [ "New Help Request" ; Parameter: @helpParam ( $scriptComment ) ]