callFunction (that includes a study)

[mbuta]

Hi,
I was told that callFunction is like having that function in your calling efs. This means that something like this should work (and it did work until my HD crashed):

calling efs
...
var xxx = callFunction (""location/yyy.efs", "fake")
..
****************
where in yyy.efs

function main() {
}

function fake() {
return studyXYZ.getValue(MAStudy.MA)
}
**************

The error mesage I get is that in function fake studyXYZ has no properties.

NOTE1: studyXYZ is defined in both calling efs AND in yyy.efs.
NOTE2: If I include the entire function in calling efs it works.
NOTE3: if I give fake the study name as parameter also works (but I don't want to do this because I work on several studies, with already many input parameters, so would be a mess).

Can anybody tell where my brain damage is?
Thank you.




I had this working before i lost my HD.

[gspiker]

studyXYZ.getValue(MAStudy.MA)

Can you post what your setup of this study looks like? I suspect it has something to do with that.

Also, and I doubt its your problem, but I would make sure you end the above statement, and the callFunction statement with a semi-colon.

[mbuta]

Hi Spiker,

Yes, I do end the statements with semicollon.
Please note that:
1. If I copy the function into my efs =>works fine.
2. If I pass the study name as parameters also works fine.
3. I tried this on several function I have and they all behave the same: do NOT recognize a study from the calling efs unless you pass the study name as parameter (this is a feature that is not advertised but works).

Thank you.
Mihai

[gspiker]

Hi,

I do the same things and it does work.

If you didn't have the study defind in the called EFS correctly that could account for the problems and would explain #1, but not why #2 works, unless EFS passes addresses and not values if it is a function...then #2 does make sense. But I doubt it does...


Since you haven't posted up any code, I assume you want to keep it private. Might I suggest that you come up with some simple EFS that shows the problem and post that up. I will take a look at it.

Garth

[mbuta]

Hi Spiker,

Is not that I want to keep it private, I dont know how to upload the efs file from the other computer and to copy it here is too large.

I will try a simple example, as I did try on several functions I have:

*************************************
Calling efs:

var study1;

function premain(){
{
function main() {
if (getBarState()==BARSTATE_ALLBARS) {
study1 = new MAStudy(10,0,"close",MAStudy.SIMPLE);
}

var xxx = callFunction("location/ZDY.efs", "fake"); //this does NOT work
//Alternate:
var xxx1 = callFunction("location/ZDY.efs", "fake1", study1); //This works

}

In ZDY.esf (study1 is defined identically, as calling efs is a copy of this one).
...
} //End main

function fake() {
return study1.getValue(MAStudy.MA);
}
function fake1(studyName) {
return studyName.getValue(MAStudy.MA);
}

As you can see, the only diference between fake and fake1 is that in fake1 I pass the name of the study, which is study1, like I try to use in fake.
If I copy fake into the calling efs, also works.
This tells me that callFunction does not "see" the global variables and their properties declared in the calling efs.
If you need more info, I would be more than happy to send you the actual efs.
Also, if you have an example that works, and can share, please post it.
One last thing, I use Build608 and I dont know what build I was using when it worked.

Thank you for helping me.
Mihai

[gspiker]

Hi,

OK...I got it. Yes, I don't believe the called function will know about the local globals on the calling function. I usually pass such things as variables and arrays in the parameter section...occasionally I will use universal globals (setGlobalValue(), getGlobalValue), but these have some overhead associated with them and make the code more cluttered as well.

I didn't get what what you were referring to previous about the study name...but the example clarify's nicely.

I notice in NOTE3 on the original email you state:

NOTE3: if I give fake the study name as parameter also works (but I don't want to do this because I work on several studies, with already many input parameters, so would be a mess).

universal globals could be a way of doing this, but perhaps the cleaner/easier way is to instantiate the study in each of your called functions.

[mbuta]

I tell you it worked in a previous build and it should work if callFunction is what it is supposed to be: a part of your efs, which happens to be located elsewhere.
this is the main reason callFunction was created, to address limitations of call(), which gets instantiated every time you use it.
I think it is a bug that should be addressed.

I was surprised to see that passing the name works, which I think is occurred and should not work, but it does and is a nice extension of study of a study feature.

One can apply any function, to ANY study.
Here is the general formula:

callFunction("location/efsName.efs", "functionName", studyName, TypeOfVariableToReturn, parameters)
where:
studyName is name of the study in calling efs.
TypeOfVariableToReturn = "MAStudy.MA", or "ADXMStudy.PDI", etc.

In the function do:

var xxx = studyName.getValue(eval(TypeOfVariableToReturn));

By the way, are you from eSignal support team? If not, is there any eSignal support team under some obligation to address our problems? I think we deserve at least that much for all the money we pay every month.

Greetings,
Mihai

[gspiker]

Well, it isn't exactly the same. Never was. I can tell you why it was created and what it was intended to do, because I was the one who requested it and worked with the engineer to verify it worked. Same with the original call() function.

The intent of call() was code reuse, period.

The intent of callfunction() was as you suggest. So its intent was to permit code reuse without forcing iterations of the charts. Period.

Having used callFunction before it was even know to exist to the rest of the world, I can tell you at THAT time, as in THIS it never would use local globals. Now there MIGHT have been a time in between when it did, but nobody ever mentioned that as a feature enhancement if so.

And no, I am not with eSignal, and I bet someone from eSignal will reply. But this would be treated as an enhancement request I'm sure, and not a bug, as it was never intended to work the way you suggest.


Calling with the name works, because you are not really calling with the name, but with the instantiated study object.


Garth

[eSignal_JasonK]

Hello Mihai,

Garth's understanding and interpretation of the behavior and usage of call() vs. callFunction() is correct. A formula that is called by another does not have access to the calling formula's (parent) global variables. There are two ways to make those values available to the formula being called (child). First, you can pass the variables as parameters in the callFunction statement, which may be a study object. Your other option is to use setGlobalValue() from the parent EFS and use getGlobalValue() in the child EFS.

As for your code routine you claim worked in the past, but not now is a mystery to me. It shouldn't have worked. There may be some other logical explanation, but without having the code from the original formulas, we can only speculate. Is it possible that you had a study object with the same name instantiated in both the parent and the child formulas? That's the only possibility that I can think of that would have made your routine possible.

[mbuta]

Hi Jason,

Thank you for clarifications.
Mihai