Boolean FunctionParameter Interesting Behavior

[Guest]

I thought this is an interesting exercise, so I am posting. It documents what I think is some interesting behavior in the new FunctionParameter functionallity.

Load this efs, Boolean is a String, and run it with the formula output window open. You will see the output in the formula output window "I am a Boolean"

Now is where it gets interesting. Pull up edit studies and go into the Boolean is a String study and select the true boolean value and then apply it. Now look at the formula output window.

The new FunctionParameter assignment of this variable as a Boolean true has changed the variable type to a string. I am thinking either I have some small error in my code that I cannot see or this is unique to the new FunctionParameter assignment.

Does anyone have any ideas?

[gspiker]

Steve,

I didn't run your test, but I belive I have run into what you are saying. For some reason the function parameter code really doesn't do Boolean correctly - instead you will get a string of "true" or "false".

I never reported it as a bug, since it really isn't that big a deal...except it might cause some coders initial confusion (as it did me, and apparently you also).

It could be that there is an issue with passing a boolean as a paramter to any function in JavaScript. It would be easy enough to test it one were the really curious sort...which in this case I'm not ;-)

Garth

[Gavishti]

I reported earlier that the Boolean function parameter does not work properly. Although it looks like it works, when testing the changes in Edit Studies they do not make it through to the efs. So you are stuck with whatever default value you set. I asked for an estimate of when it will be operational and have not yet received a reply.

Switched all of my code to strings of "Y" and "N".

[Guest]

FWIW, the work around I started using is that I check for the logical condition or the string value. I figure that will cover all conditions.

if ((pCalc == "true") || (pCalc == true))

[ACM]

Interestingly enough it does seem to always work in certain conditions such as the one in the attached efs
Alex

[gspiker]

At the start of your main()...why not

if ((pCalc == "true") || (pCalc == true))
MyGlobalBooleanpCalc = true;
else if if ((pCalc == "false") || (pCalc == false))
MyGlobalBooleanpCalc = false;



and then use MyGlobalBooleanpCalc (of course you can use a smaller name) in the rest of the code?

Slightly more efficient, and certain to produce cleaner looking code. And if you use pCalc in functions other than main and define MyGlobalBooleanpCalc as a global you don't have to pass pCalc as a paramter to that function.


Garth

[Gavishti]

A boolean compare is more efficient than a string compare. However, you are doing a boolean compare and a string compare to assign a boolean value so that you can do a boolean compare. Don't fight the inefficiencies of the tool. Until they get the boolean feature of function parameters reliably operational just use a string compare.

[gspiker]

A boolean compare is more efficient than a string compare. However, you are doing a boolean compare and a string compare to assign a boolean value so that you can do a boolean compare. Don't fight the inefficiencies of the tool. Until they get the boolean feature of function parameters reliably operational just use a string compare.

This is silly. You are saying " ignore improving the efficiency of
doing both a string and boolean compare everytime (which is what you have to do, because in some cases you do get a boolean), ignore having your code be clearer and cleaner, and ignore the fact that once they do fix it you will have to change multiple lines in every EFS you used this method on - because I don't like the fact that eSignal has a bug".

Do you often cut off you nose just to spite your face?

G

[Guest]

Alex,

I downloaded the Price Oscillator example you downloaded and modified it slightly to indicate the state of the boolean value. It does change to a string when you open edit studies and check ok.

It does work though as you indicated. It probably is something related to what Garth had previously posted. Passing to the function, the boolean is changed to a string, so it does not matter if you pass a string to the function, since that is what is passed anyways.

I like your solution Garth, since often I use these in functions within the code so they need to be globals anyways.

Gavishi, you are correct, I do not mind working with small work arounds such as this. In so doing, I have observed some other interesting behavior with the file that Alex posted which I would post to the BB as follows:

I took Alex's file, modified it slightly and renamed it. After running and modifying several times, I renamed the file again and retitled the study.

Here is a screenshot (cannot access fileshare, so I will attach and continue with another post)

[Guest]

notice that in both price oscillators have not been modifie using edit studies yet and the outputs are booleans.

Now I go in and modify only one of the studies, In the attached file below, you will notice that the outputs are both changed to strings and that both the efs titles indicate that they have been modified with edit studies, even though I had modified only one.

Now this could be by design (the way new FunctionParameter has to work, modifying all similarly defined variables within the envelope of an advanced chart), but I did not expect this behavior.

What this tells me is that if you have several efs's in one advanced chart, and they share an identically named new FunctionParameter, by modifying one of them in one of the studies, you may inadvertantly modify the like named new FunctionParameter in the other study.

Anyways, food for thought when using this excellent feature.

[ACM]

Steve

What this tells me is that if you have several efs's in one advanced chart, and they share an identically named new FunctionParameter, by modifying one of them in one of the studies, you may inadvertantly modify the like named new FunctionParameter in the other study

Unless I misunderstood your explanation and am not replicating the process in the same exact way this is not happening at my end with two copies of the same Price Oscillator efs running.
If I change the true/false on one of them the other one does not change.
Alex

[Guest]

Alex,

I had not taken my theory to the next level, I am glad you did. I actually changed one from false to true and the other did not change. I will attach the file.

My point still is somewhat valid though, in that when I went to edit studies and modified only one efs, that the booleans used in that and the other efs's in that advanced chart, which are set using new FunctionParameter, are changed to strings.

Thanks Alex and Garth for all the help!

[J. Arps' Programming Coordinator]

the proposed recommendation is invalid

I just wanted to make you all aware that the proposed solution

if ((pCalc == "true") || (pCalc == true))

will not work due to the fact that when any initialized string of any length is tested as a boolean it returns TRUE. Therefore, even if pCalc actually is the string "false" when pCalc==true is evaluated, it will be boolean TRUE and since it is being OR'd the complete statement will evaluate as boolean TRUE. I came across this same problem, tried this same solution and to my dismay realized this problem. Interestingly, a non-initialized variable evaluates to FALSE - perhaps this could be used to some advantage but I have not thought of it.

I have attached a very simple example of this problem, along with what I have been using as a workaround. Basically, I simply define a STRING functionparameter with options "true" and "false". Then, whenever i need to test, i only test it as a string. This is more tedious and obviously not as efficient as a BOOL compare but we have to work with what we've got. At least this way, you are not as reliant on the end user having to accurately type something in... also the input is still "clickable" to change it's setting - and best of all, if they ever fix this your old code will still work just the same!

[J. Arps' Programming Coordinator]

Attachment for previous post

Here is the attachment that should have been with my previous post.

[Guest]

Thanks for bringing this up and for providing an alternate solution. FWIW, I have not re-evaluated this, however, it is a safe bet to evaluate strings as you suggest.