Arw_new strange reaction

Hello.

I'm having problems with the following formulae:
If you see the image attached, you'll notice a series of arrows, and I can't understand why is that.
I only want one simple arrow on top of the bar that end the time selected on the input.

Regards,
Fernando

try this:
(ps. I have not tested it because my MC is closed)

hi tj

im not at home at the moment, so i cannot test your formula, but as far as i know, since i'd tested using it, creating the arw inside the currentbar=1 statement will only plot the arrow in today's session, not for the historic chart, and, in this example, the arrow will also not be plotted at the bar's high price as specified, but above of that same high.

regards,
fernando

ps:sorry for the lack of capital letters and such, but im writing this message on my pda at a train station

I don't see an Arw_mew statement in your code Fernando.

It appears you are trying to highlight a range of times from a start time to an end time (maybe the same every day for a series of dates - not sure).

Why not do this so avoid many arrows.

1/ I rarely look at my paintbar code but I think you are trying to paint the bars yellow between the start and end time (inclusive). Painting the bars between the start and end time makes sense.

2/
use Arw_new once at the very first start time
(if time = StartTime and maybe use date = StartDate)
use another arw_new statement at the end time
(if time = EndTime and maybe use date = EndDate).
That way you get a simple start and end marker to add extra highlight to the range of bars. If you want to mark it over many days just leave the date test off.

I think I can safely assume you do not want an arrow on every bar.

Note that the primary reason to create an arrow on the currentbar=1 code and move it later is if you want to create an arrow for immediate use on a LastBarOnChart bar (one that has not yet achieved BarStatus=2 status - one that is not complete yet). This is because if the bar is not complete yet the arrow keeps getting deleted on every new tick and the Arw_New command keeps having to redraw the arrow until barstatus = 2 is finally reached (when the bar is finalized or finished). Therefore if you use arw_new on any historic bar that is complete the arrow immediately locks in place because the barstatus=2 is true already. Note that the ID that is assigned in the Arw_New command can only be trusted to stay the same if the arrow has finally locked when the arw_new command was executed during the final BarStatus=2 tick of the bar. Having said all this, sometimes if I have some lines, arrows or text that I am going to be moving around a lot I will create them all on currentbar = 1 then move them when needed. I do this rather than having to delete and recreate over and over so as to have less risk of MC getting mixed up with ID codes and deleting things it should not delete. So I guess there are two reasons to have an initial create of arrows/text/lines on currentbar = 1. However it appears that this app does not need to worry about any of this.
John.

Hi John.

I don't see an Arw_mew statement in your code Fernando.

Actually there is.
Look at line 22(?) My main objective is quite simple and, after reading your detailed explanation, quite basic I must say.
Through the paint bar statement I'm selecting the European and US cash markets. Since there is a time period where both markets are open together, I mark the end of the European markets with the arrow.

This is something not be used in realtime, but rather for offline and historic studies.

I was able to plot the arrow like I wanted to be plotted on a historic chart: Please see image attached (I hope tssupport resolve the image colour issue on version 7).
There are 2 problems with, first the study plots an arrow on the last bar chart, and second although there's enough data on the first day on the historic chart, no arrow is being plotted on it.
Naturally that this 2 issues don't affect the results that I want to get from this study, but they are there, showing me that the study has a problem.

I was not able to plot the arrows like shown in the image using currentbar= 1.

How do you move the arrows into wherever you want on the chart using the currentbar?

Fernando

Hi Fernando,

I missed the arw_new statement because your indenting is different than my indenting and I guess I must read any line immediately above an indent as an IF statement and normally arw_new is not in an if statement.

I copied your code into the editor and forced it into the indent system I use based upon where the begin and end statements are (in other words the way the compiler will read it). Note: that I now create an if statement completion comment that has the indent designed to line up with the IF statement to make it easier to read. This way it is mentally easier to have the "begin" and "end" statements properly indented to match each other. This allowes the effected statements to match the "begin" and "end" indent to match up with the logic that is occuring. In short it makes it easier for me to scan it quickly exactly the way the compiler will read it.

I also separated the if statements which have no "begin" and "end" from the other code so it is easier to see that these if statements effect only one line of code.

I also used another comment technique where I use a "START:" statement and "END:" statement to block the code to make it clear very quickly to the eye exactly what code is being effected by the very first if statement.

After I got a clean compile using this indent technique, I copied it into the forum inside the forum "code" statement and it managed to maintain the proper indent line up (surprise!!!! surprise!!!!). Maybe I can understand the logic faster this way. I don't understand the current problem just yet actually. So I am going to let it sit here a while and see if anyone sees any problems using this code line up and commenting technique.

I think you need to change your code to this. If you study my first version of your code compared to this version you will probably detect that the arrow modification statements are working over and over again when they only need to be executed one time. this code fixes that. Notice how I ended each of the If statements with the (END: whatever} comment to mark them as finished and I used the proper indent to match the if statement. Using accurate indenting I believe is a big help in reducing bugs.

Hi John.

Thank you for your help identifying the problem.

At the end it was as simple as correctly nesting the "if" statements.

I didn't use the "begin...end" statement because since I'm not declaring several variables in the same statement, I thought I didn't need to block/close it.
To tell you the truth, usually I test both ways to see if there's any difference, but in this case, that didn't go through my mind.

Regarding the indent (I was forced to look this one in the dictionary), it's very "clean", no doubt about it, and if you have a compiler that do that automatically, well, even better.

Each one of us write the code in the way we understand better. Mine is not that different from yours.
Comments are really the best way to help us identifying which piece of code relates to which (my god, the time I spent trying to understand things that I and others wrote just because there's no comments on them).

Yes comments help later when we forget what we did and come back. I think we all have to come back at times even it is just to insert new suff without changing the old. I have done that many times with EL (especially my wave marking code). Without proper indending of related items figuring out code becomes a pure nightmare. Numbering the if statements can be very handy (something I just started doing). I will get the URL with that.
viewtopic.php?f=5&t=7142
I am finding the new {END: if whatever then} comment is very useful too. I am just getting use to it but once one gets use to a new proper technique it because auto-pilot and hard to do without.