unwanted reloading study required

[tilmon]

I have created a script which runs OK, and in different time intervals. Let's take a 2 min interval for a chart with this study. At the 2 min time, it updates the values, but does not completely rescroll to the right with the cursor, so I have to right click on the chart and click "reload". Also, in this study I have created a "shape", a black dot for current price (I use "getValue("close",0), and every two minutes that balck dot updates and jumps to its new vertical position. But, I would like to have it update continuously, just as if it were a cursor. But, I return no values at the bottom of function Main.
SO, I have an embarrassingly simple problem, of not knowing how to "cycle" my script to update and advance automatically, nor how to get certain variables to update continuously between "interval" study udates.
Can you help me.
I need an example of how to return and update automatically without having to reload. I am not using the right side as a normal point of reference, but the left side. That is why I am not returning values as cursors (proabably a source of error). It is a profiles style study with values posted to the chart as "offsets" from the right. This has confused me about how to update values on the left without naming tham as cursors, etc. The simple black dot is for
"price" meant to move along the rounded edge aof the bell curve
tkx,
Tilmon

[eSignal_JasonK]

Hello Tilmon,

Unfortunately it is not possible to provide any solutions for you without seeing the code you are working with. Please attach your formula code.

[tilmon]

reply to JasonK

Jason,
I posted a thread last week about a problem of a program not updating in real time but oanly at interval clickover. You replied that it would not be possible to help me without seeing the code, so I replied to your e-mail (notifying me of your post-reply) by attaching the script to that email reply. I am new enough that I did not THEN yet know that scripts could be attached to these threads. I just learned that this week. Anyway I have not hearde back form you in reply to the script I attached to the email. SO, my question is "do attachments in reply to email notifications of forum post replies not get through?" I know the entire support team relpies swiftly to all posts, so after 3-4 days, I KNOW I am doingsomething wrong in my communication.
I have a "drawShape" black dot which I am trying to use as a price cursor, not in main, but in a function for drawing lines above main, and it only updates when the time intervgal clicks over, like every two minutes. I would like it to update in realtime like a price cursor. I'll try and attach it to this thread. It's a profile study that refers to having been posted here before, but I couldn't find it in the library now.
I "/// remarked" it to highlight my problemareas, and added detailed preamble near thel beginning , listing the problems with specific line references.
Will aprreciate nay help.

Thx,
Tilmon

[eSignal_JasonK]

Re: reply to JasonK

Hello Tilmon,

Originally posted by tilmon
Jason,
I posted a thread last week about a problem of a program not updating in real time but oanly at interval clickover. You replied that it would not be possible to help me without seeing the code, so I replied to your e-mail (notifying me of your post-reply) by attaching the script to that email reply. I am new enough that I did not THEN yet know that scripts could be attached to these threads. I just learned that this week. Anyway I have not hearde back form you in reply to the script I attached to the email. SO, my question is "do attachments in reply to email notifications of forum post replies not get through?" I know the entire support team relpies swiftly to all posts, so after 3-4 days, I KNOW I am doingsomething wrong in my communication.

Replying to the email notification (with or without attachements) will not be received by us. It is simply a notification that someone posted to a thread or forum that you are subscribed to for email notification. To reply, you need to log in to the forums and click on the "Post Reply" button within the thread in which you want to post a reply. To help keep conversations organized here in the forums you should reply to the thread you are corresponding with. Your original post that I am replying to was created as a new thread because you clicked on the "New Thread" button in the EFS Studies forum. I went ahead and merged your post to the thread you were referring to.

I have a "drawShape" black dot which I am trying to use as a price cursor, not in main, but in a function for drawing lines above main, and it only updates when the time intervgal clicks over, like every two minutes. I would like it to update in realtime like a price cursor. I'll try and attach it to this thread. It's a profile study that refers to having been posted here before, but I couldn't find it in the library now.
I "/// remarked" it to highlight my problemareas, and added detailed preamble near thel beginning , listing the problems with specific line references.
Will aprreciate nay help.

Thx,
Tilmon

What you are asking for here is going to require a significant amount of work. I will not be able to respond to all the items you are trying to accomplish in one post. Let's address the problems you are encountered one at a time and work our way through it. So for starters, what I would recommend is commenting out all the modifications and changes you've added except for the first item you're working on. Attempting to add a multitude of modifications all at the same time without ironing out the kinks for each one as you go is probably complicating the process for you. Before we can tackle the issue you described regarding the black dot, we need to back up to the beginning and address the run-time error that is occurring when this formula is first applied to a 1-min chart of IBM.

Within the addTPO() function on line 324, the drawLineRelative() function is generating the following error.



The reason this is occurring is because the first parameter is using a local variable, vdrawOS, that is undefined during the loading process. This variable is only being created when the conditions on lines 207 and 245 evaluate to true, which does not occur on each historical bar during the loading of the formula. What you need to do to correct this is move all of the logic you added from lines 312-326 up so that they are contained within the condition that starts on line 245. That will ensure that when the drawLine call is executed, vdrawOS will contain a valid number. The easiest way to make this change is to move the end brace (i.e. "}" ) that is on line 310 to line 327 just above the return statement for the addTPO() function.

Work on this item first, test it and see if it works as you had intended. Post your updated code and details and we'll continue from there.

[tilmon]

First Fix done.

Jason
I have made the first correction of the run time error you cited. Thanks for directing me to find this reply facility. I shall attach the correctedd script with fix #1. I am using the 2 minute e-mini contract YM_Z6. Hence the prices move at 1 point per tick (which is easy), compared to 0.01 per tick for stocks.
Also, I am learning about Apache for the first time (by Googling it) and appreciate you guidingme to more powerful help resources. Is Apache something I can download and use to do some of this work myself?
Trying to do all I can before asking for help.
Thx.
Tilmon

[eSignal_JasonK]

Hello Tilmon,

I see that you have corrected the syntax error and that the formula is now executing. If it is performing as you are expecting up to this point, then move on to the next item you're working on. If you run into a specific problem, post the details and your updated code.

Apache has nothing to do with EFS so it will not be useful to you for EFS development. Apache is the server-side web technology used for these forums.

[tilmon]

reply--2nd effort reloading issue

Jason,
Thank you for following up. I made the first correction and attempted to attach it to my reply, several days ago. First timer effort, but the attachment obviously failed. If you do not get the corrected script attached with this, please let me know, and I'll send a new post with attachment. I think I can do that. This is a second re=type of this reply, the first one crashed on a bad finger stroke. Is there a tutorial anywhere that tells how to use all the buttons in this facility? Like what are the IMG, PHP, LIST, buttons for at the top. I know what they stand for )Personal Home Page, Image, etc) but I don not know their parameters of usage. I don't like to go experimenting around , pressing buttons on a computer that trades real money, unless there is an operating manual. So, I have been living and learning one mistake at a time how to use these forums.
I also just discovered how to find the back pages thru the tiny little page numbers at the bottom, and have begun reading a few pages every night. Have copied all the magazine library scripts and file forum scripts (yours mainly) into volumes of 3-ring binders, and study for clues every problem before posting. Now I will be into the thread responses as swell. Thanks for the tip.

Ok, on this script I made the prior correction and moved the curly brace (per your suggestion from line 311 to 327. That stabilized the red/green line, but did not entirely fix it. I have had a week to watch it operate on chart, and it still gets off. The idea here comes from Profile trading theory which suggests that a trader try to execute trades on the"side" (top/bottom) of the bell curve which has the greatest "opportunity". That would be the "widest" side, because there are more vertical price points to work with there, than on the narrowest side. The relative lengths of the red or green lines,in relation to the widest blue horizontal line (Max tpo Count) tells the viewer whether the top (sell high--red line above) or the bottom (buy low-----green line below) is the side to trade from.
So the idea is to have a live traffic light flashing Either/Or, red line if above, or green line if below (never both)(no line or makes no difference if price cursor exactly at widest blue line) The problem to me seems to be in scaling. Price is vectored up and down the left spine base of the bell curve as measured by the array aMPprice[i]. But, it is a scalar created in the script proportionate to real price intervals and graph proportion, representeded by the variable "qty" (quantity of real world price ticks per horizontal blue line (pixelated) intervals).
I just want to display either red or green, while cursor prices are either above or below the ever adjusting widest blue line. traffic light style. When the price cursor drops down below the widest blue line from above, the RED line above should disappear, and the GREEN line below should pop up. For scalpers or "faders", this helps to show which side to trade from, especially when one is close ianto the middle, in an ever changing profile "shape".

That was the side show. Hope you can help me with that., and can stand going back to the main issue.

The main problem is the black dot, and the fact that I have to manually reload the script to get current readings during the trading day, except at time interval updates. It only updates when the time interval (like 2 minute) "clicks over. "On a fifteen or thirty minure chart (which are the most commonly used for profiles) this means the profile in this script does not update for 15 to 30 minutes, unless I right click and use "reload". So, the black dot "jumps" once every 15-30 minutes, sometimes 10-15 points, instead of flowing smoothly along the bell curve in real time.The real problem is that as a newer EFS programmer, I do not have clear understanding of the structural requirements for a script to make it perpuetually updating in real time, vs, only at interval turnover. I would love to understand better what I am doing wrong, or "need to do right" to make certain variables return continuously updated display, vs those that only "compute on close" I am not using Compute on Close in this script, but it is acting like I am, and I do not know why. My inability to articulate code (or overall script architecture) which can produce these separate frequencies of updated displays is the real problem.



I have sen scripts with dozens of "cursors", like a script with 20 "pivot lines" all stacked up, but do not know if that is a software design I need here.

Thx again for your many helplful responses these last few days, I hope this request is not one too many.

I' shall be pleased to run as many corrections at this end, and re-attached scripts to you as needed, one step at a time.

Tilmon

[eSignal_JasonK]

Hello Tilmon,

To learn more about how to use the forums, please review the forum FAQs. After reviewing these, you can experiment with the various forum tags by previewing (click "Preview Reply") your post. Just close the browser window when your done. Unless of course you want to post. Then click on the "Submit Reply" button.

Regarding the black dot and the timing of it being redrawn lies within the series of conditions in the formula starting from within main(). Your drawShapeRelative call is inside the addTPO() function, which gets called from within main() when one of the encapsulating conditions evaluates to true. The reason the dot isn't redrawn on every tick is because the conditions that encapsulate the calls to addTPO() do not evaluate to true on every tick. The original formula was not designed to update on every tick, which is why it has this series of conditions. What you are attempting to do with this formula isn't question a of whether or not you are doing something right or wrong. It's a matter of creating a set of formula logic to perform one way or another based on your desires. To have this dot draw on every tick can certainly be done, you just need to add this code to an area that will be allowed to execute on every tick.

One logical place to perform the dot logic would be inside main() just above the return statement. Make sure that you don't put it inside any conditional statements that will prevent it from executing every tick. By default, main() will get called on every tick unless the formula is using setComputeOnClose() or you've turned on the compute on close option in the EFS Settings. So, move the code logic for drawing the dot to this location in main(). You will also need to duplicate the logic from addTPO() that sets the values used for the x/y coordinates for the drawShapeRelative() call.

Another thing you could do to help keep your code organized is to put your dot logic into it's own user-defined function, such as drawDot(). Then inside main() just above the return statement make a call to drawDot().

function addTPO() {
    ....
}

function drawDot() {
    ... drawShape dot logic here
}

function main() {
    .... 

    drawDot();

    return null;
} 

[tilmon]

black dot fixed

Jason,
Thank you forl your reference to the Forum explanatory materials. I shall go thru all that this weekend.
The black dot is fixed. I would like to express my gratitude for articulate manner in which you explained the "encapsulization "process. I absorbed a valuable lesson from that, and I am already reviewing other scripts I have written for that error, and noticing how that works in library scripts.
I tried both methods to fix the black dot. First, I just put all the code related to it in a small stack at the bottom of main, just above return null. That worked. Then I went on and moved that code up into a separate function "drawDot" placed just above main, and left only the single line entry near the bottom of main to call "drawDot();" That also worked.
As the second of the two methods seemed to me to be the more elegent algorithm, I chose it.
The attached script labelled "Correction3" includes the fixes to date, and a clean out of the un-needed "///remark" lines and extra white space.
There is still the matter of the red/green line, and I am hoping you will have an opportunity to review that. I left the remark lines only that relate to it.

Thx,
Tilmon

[eSignal_JasonK]

Hello Tilmon,

I'm assuming that you want the red/green spine for the profile to update tick-by-tick in the same manner as the dot? If that is the case, then the solution is nearly identical as that for the dot. The logic for drawing the spine is also inside the addTPO() function, therefore it is subject to the same timing issues that you experienced with the dot. You probably can guess at this point what the solution will be. Just like with the logic you moved out to the drawDot() function, you can also move the drawing logic for the green/red spine there as well. You could alternatively put the spine logic inside it's own user-defined function and execute it at the same place as drawDot() in main(). Just as in the solution for the dot, you will need to duplicate any logic from addTPO() that assigns the values to the various variables used in the drawing functions.

function addTPO() {
    ....
}

function drawDot() {
    ... drawShape dot logic here
}

function drawSpine() {
    .... drawLine logic
}

function main() {
    .... 

    drawDot();
    drawSpine();

    return null;
}