I’m hoping someone might be able to help me with this one.
I have a script that perfomes a simple function:
function foo
...
Do Stuff
...
end function
I have another script that wishes to use the helper function:
Properties
helpers: (FooScript)
End Properties
put foo()
The code as above simply doesn’t work. The helpers are not recognized. This is the format specified in the documentation, however. According to documentation as I understand it, the script that calls foo should be able to do so with no problems since foo is set as a helper.
Any clues would be greatly appreciated! Thanks in advance!
Have you taken a look at page 165 of the SenseTalk Reference manual? I was bitten by the assumption that properties are magically part of my object. They aren’t (or at least not always).
Namely, the section I am refering you to is:
to initialize
add properties of this object to me
end initialize
-edj
(from 165 of SenseTalk Reference:)
Assigning Default Initial Properties to a New Object
When a new object is created from a prototype, by default it inherits all of the behaviors of the prototype object, but none of its properties. The only properties it starts off with are those supplied in the new expression. A prototype object can provide a default set of initial properties for the new object. One way to do this, as already mentioned, would be to write a custom makeNewObject function. A much simpler (and better) choice, though, is to take advantage of the “initialize” message that is sent to the new object. Here is an example initialize handler that provides some default properties:
to initialize
add properties (time:“12:00”, priority:“Normal”) to me
end initialize
If this handler is in a prototype Appointment object, then a new appointment can be created like this:
put a new Appointment with (time:“8:30”) into meeting
This will create a new object helped by Appointment, with its time property set to “8:30” and its priority set to “Normal”.
A slightly different approach would be to use properties of the Appointment object itself to serve as the default values for the new object. Here’s another Appointment script that shows this approach:
Assigning Default Initial Properties to a New Object
When a new object is created from a prototype, by default it inherits all of the behaviors of the prototype object, but none of its properties. The only properties it starts off with are those supplied in the new expression. A prototype object can provide a default set of initial properties for the new object. One way to do this, as already mentioned, would be to write a custom makeNewObject function. A much simpler (and better) choice, though, is to take advantage of the “initialize” message that is sent to the new object. Here is an example initialize handler that provides some default properties:
to initialize
add properties (time:“12:00”, priority:“Normal”) to me
end initialize
If this handler is in a prototype Appointment object, then a new appointment can be created like this:
put a new Appointment with (time:“8:30”) into meeting
This will create a new object helped by Appointment, with its time property set to “8:30” and its priority set to “Normal”.
A slightly different approach would be to use properties of the Appointment object itself to serve as the default values for the new object. Here’s another Appointment script that shows this approach:
to initialize
add properties of this object to me
end initialize
properties
time:“12:00”, priority:“Normal”, objectType:“Appointment”
end properties
properties
time:“12:00”, priority:“Normal”, objectType:“Appointment”
end properties
Actually, yes, I should have put that in the code sample. I do make a call before calling the function
add the properties of this object to me
However, the helper scripts do not appear to be added along with the other properties of the object.
As a clarification, if the script that uses the helper objects has an Initialize routine that is fired, then for some reason it DOES include the helper objects.
But if the script has no initialize routine and just “runs”, it does not include the helpers.
The short answer appears to be this: You need to put quotes around the name of the helper script, like this:
properties
helpers:("FooScript")
end properties
I believe this worked without the quotes in an earlier version, which would treat the script name as an unquoted literal. I’ll have to look into what changed along the way that led to quotes being required now.
The answer given by edwindjb is a good one, and might have been the problem if you were treating the main script as a prototype object. I was working on a longer answer to clarify all this when I discovered the need for quotes, which I believe is probably what you’re actually running into.
Your last clarification indicates that it works (without the quotes) if your main script has an initialize handler that is called. My tests confirm that the quotes are not needed if the script is first loaded by a “new” expression – apparently the need for quotes is due to a bug that only applies in certain situations. In any case, I believe that once you add the quotes you won’t need to “add the properties of this object to me” or to create a new object, etc.
If this doesn’t solve your problem, or you have other questions, please let us know.
The command “add the properties of this object to me” should not be needed. Declaring the helpers property the way you indicated here worked for me in my tests. However, I have also discovered that the bug may run somewhat deeper than simply a problem of quoting.
I suggest that you email your actual scripts to support(at)redstonesoftware(dot)com so we can see exactly what is going on, and help you to overcome the problem. I can’t see anything wrong with what you sent, but it’s not complete enough for me to diagnose the problem without more information.
I’m new to this forum but wanted a response to an extended issue of using Helper suite.
Issue 1:
I have one suite say one.suite and another one called two.suite.
two.suite is added as Helper suite for one.suite.
I have a script called systemlib.script in Scripts folder of two.suite with a function called testnum.
Question 1:
How can I call the function “testnum()” from a script in one.suite? Can I do that?
Issue 2:
How does the “start using “script”” command works cuz I faced the following problem:
I have one suite called one.suite.
It has following folder structure:
Yes, you can call it, but the Helpers suite mechanism doesn’t get you there – it only lets you see the scripts in the helper suite, not the handlers within them. To call the handler, you’ll have to specify which script it’s in:
put helperScript's testnum()
This is also true if helperScript is in the same suite as the calling script. If it’s in a different suite, you can call it as shown above only if that suite is open as a helper (otherwise you would need to supply the full path to the script).
Eggplant doesn’t really support subfolders within the Scripts folder. You may get away with doing this for some things if you really work at it, but I think you’ll find yourself fighting the system all the time. To organize different collections of scripts, the recommended approach is to put them in different suites.
[quote=“Kool_Friend”]
The mainscript has following two lines:
start using “script3” // start using library by calling single script
put function1()
The script3 has following code:
function script3()
start using “lib/script1” // include the firt main lib and later add other lib
end script3
script1 has following code:
start using “lib/script2” //include the remaining lib files
function function1()
do something
end function1
Question:
There is an error stating that could not find Handler for Function “function1()”
Please respond.[/quote]
Putting aside the question of nested script folders for the moment, the main problem here is that the “start using” command inside script3 is never executed, so script1 is never put “in use”.
The potentially confusing point to understand here is that the “start using” command is just that – a command. It isn’t an “include”-type mechanism like you may have used in other languages. So a start using command has to be executed as part of a script in order to have any effect. Note that the actual list of scripts that are “in use” at any time is contained in “the backscripts” global property (you can also change the list by inserting or deleting scripts directly in this list), so you can examine it with “put the backscripts”.
Another way to make handlers in another script available is to assign the other script as a helper of the current script (using the “helpers” property, as discussed earlier in this thread). This “script helper” mechanism is similar to helper suites, but on the script level. Both helper mechanisms automatically make a helper’s helpers (and their helpers, etc.) available to the script being helped, so this would be another approach for you to consider that might give you what you’re looking for.
The reason of having subfolders is that we want to maintain library, scripts and images in a modular form and also we want to replicate the folder structrue that we define in Clear Case.
Making things modular is a good idea. You can mimic your Clear Case folder structure at the Suite level, just not within the Scripts folder inside a Suite.