Beginner problem: Passing a some script variables...

[El_Pablo]

Hi,

I'm having a problem passing some variables through a script.

Here's my script (I'm using french version)

Run Script("ExportImage";Parameter: 

"Let (

[

$ImageFolder = $$FolderTrvVente;$ImageFilename = $NameImage;$ImageFormat = $jpegFormat];

"Image parameters"

)

"  // Only works for $ImageFolder



Run Script("ExportImage";Parameter: 

"Let (

[

$ImageFolder = $$FolderTrvVente;$ImageFilename = $NameImage;$ImageFormat = "jpeg|640|480||512|72"];

"Image parameters"

)

"  // Works for $ImageFolder and $ImageFormat, but not $NameImage

I can't pass local variable why is that?

I'm new to FMP.

I learned in all other programming language that:

A --> B, B --> C then A --> C.

Why it's not true with FM??

How can I pass the parameters?

Nick

[Genx]

Try using global variables

[Ender]

The scope of local variables is limited to the current script only. This is a little different from many programming languages where variables are accessible from sub-scripts (unless overriden).

[comment]

It should work, but the receiving script must explicitly evaluate the passed parameter, in order to create and populate the variables. Otherwise it's just a text string.

See also this thread.

[T-Square]

GenX--

Using global variables is not a very robust way of solving this person's problem. Using global variables should be an extraordinary exception; consider what Wikipedia has to say about global variables:

"[Global variables] are usually considered bad practice precisely because of their nonlocality: a global variable can potentially be modified from anywhere, and any part of the program may depend on it. A global variable therefore has an unlimited potential for creating mutual dependencies, and adding mutual dependencies increases complexity."

http://en.wikipedia.org/wiki/Global_variables

Global variables, in my experience, simplify solutions in the short run, but in the long run they come back to bite you. It is far easier to figure out why something isn't working if the variables are local in scope. You don't have to chase through your entire application trying to figure out where you grabbed a global variable and reassigned it "just to test something out"...

David

[Ender]

Hey David,

Though I think there are places where a global variable is the necessary tool, I think you and the Wiki are spot on with regards to passing values between scripts.

Personally, I prefer sending of values to subscripts through script parameters. This seems cleaner and makes the sub-scripts more modular.

[Genx]

To be honest i only use global variables in order to manipulate a certain temporary peice of data through various scripts -- once the final value is worked out, the variable is destroyed so no future conflict's arise in any case.

I am still a fan of using good old fashioned script parameter's and don't really understand why the parameter in this case is not perhaps pre-calculated.

Nevertheless, the issue with the local variables here is that the parameter attempts to evaluate when the secondary script is executing at which point (in the scope of the newly executed script) the variables do not exist. Hence in this case, a global variable should perhaps be set with the parameter above, the parameter then set to be the global variable, and after the execution of that script, destruction of the global variable using: Set Variable[$$myVariable ; ""]

[El_Pablo]

Personnally, when programming in something else that FM I never use Global variable except in the case of constant such as the local path or stuff like that.

Being a professionnal programmer and new to FM world, make me realise that some technologies that seemed to be robust and flexible lack some very basic concepts of computer programming. :

For the system here, I will be patching the FM DB for a while and at the same time, I will develop a SQL Server DB. :

The FM DB in my company was develop by a non programmer more than ten years ago! And always had new tables added from month to month until last year by the same guy! Try to imagine the non relational structure... (whooaaa!) Just to tell, all the tables are in separated files and worst there's a table with 1808 fields... a nightmare for a DB developper...

I not a FM lover, but I thanks all the help you could provide me!

Nick

[Ender]

We sympathize with you. But I hope you're not ditching FileMaker because of the sins of past developers! It's really a great tool, but like other tools, it helps to use it right.

[El_Pablo]

No no, I'm not ditching FM because of previous errors. I really like to learn new stuff. I'm just passing to an another technology because of DB admin ressource. Where I live nobody knows FM. If something happens to me I need someone who will know the DB development and FM can not be kept for this reason. I live far from big cities so FM developper are scarce ressources... :

Nick

[T-Square]

Nick--

The use of global variables in FM is historic; in earlier versions of FM there was NO other way to pass information from one routine to another. Consequently, FM developers used the tool they had (global fields in tables--to make matters even worse, since you had to muddy up your actual DB structure to pass values!) to work around this limitation. FM 7 brought us a script parameter (passed as a single entry from one script to the next), and 8 brought us assignable variables. Those changes are still shaking out (in my world at least).

I can sympathize with your plight; re-working an older package (especially one with a whole lot of oddities) can be remarkably difficult.

David