Newsubject: ensuring subchart #2 lines appear

Questions about MultiCharts and user contributed studies.
bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Newsubject: ensuring subchart #2 lines appear

Postby bowlesj3 » 07 Oct 2009

For anyone reading this for the first time, the last few posts starting at "Mon Oct 26, 2009 8:09 pm" show you how to ensure that lines which you place on subchart #2 using TL_New_Self and TL_New_Self_s actually appear. You can skip all the posts on page #1. The "Mon Oct 26, 2009 8:09 pm" post appears on page #2 about 1/2 way down.

====================================================

I have been working with putting lines on subchart #2 for a few days. It appears that at times they will stop appearing and I have to turn the study off then on again and reset it back to point at subchart #2 (it always without exception falls back to subchart #1 which seems to happen on some studies for whatever reason). Maybe someone else has had these types of experiences with the subchart #2 lines.
Last edited by bowlesj3 on 30 Oct 2009, edited 5 times in total.

User avatar
TJ
Posts: 6521
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 957 times
Been thanked: 1883 times

Postby TJ » 07 Oct 2009

computers are pretty dumb... they follow instructions to a fault.


are you referring to plotting a line? or drawing a line?

I have lots of both on my charts, I've never had a problem.
Let me know how I can help.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 07 Oct 2009

Hi TJ

I am referring to drawing a line. I have lots of plots on subchart #2 with no problem ever. it is the tl_new_self_s command I am referring too.

So if these are consistently drawing for you then that is good. Maybe I can find a bug in my code. That is good info for me. It is fairly simple code and I have a print statement next to the command. Maybe I can dig further and find a problem.

I know the other problem with the study always switching back to subchart #1 when we toggle it off and on has been reported by others and I have some studies that do it and some that do not. I have never figured out why some studies have this problem and some do not.

Thanks,
John.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 08 Oct 2009

No it appears there is a problem with this function (or there was on MC 2.1.999.999 so if the TSS records of all bug fixes show that they did not fix a bug like this then it will likely be there on an upgrade). The test code pretty much confirms it (see below). It happens not too often (mostly at the start of the trading day once) and to fix it I have to turn the study off and on again and as usual reset it to point at subchart #2. Today it happened a second time and two days ago I think it also did it once in the afternoon too (tis intermittent at about 1% of calls to this function). When it happens I always get the correct print but I do not get the line as I should. And of course the values going into the function seem correct. I set the code to stop executing the function once the bar is finished using barstatus = 2 as the trigger for this.

Code: Select all


      value1 = tl_new_self_s(Date,Arw_Active_Time,LineStart,Date,Arw_Active_Time,LineEnd);
          Print( File("C:\Whatever\ALog.txt"),

                     " MySide", " " ,
                     MySide, " " ,
 
                     " value1", " " ,
                     value1, " " ,

                     " Date", " " ,
                     Date , " " ,

                     " Arw_Active_Time", " " ,
                     Arw_Active_Time , " " ,

                      " LineStart", " " ,
                     LineStart , " " ,

                     " LineEnd", " " ,
                     LineEnd  , " " ,

                     " barstatus", " " ,
                     barstatus   , " " ,

                       " ");



Code: Select all

 MySide L  value1 43.00  Date 1091008.00  Arw_Active_Time 132350.00  LineStart 72.90  LineEnd 92.90  barstatus  1.00 
 MySide L  value1 43.00  Date 1091008.00  Arw_Active_Time 132350.00  LineStart 72.90  LineEnd 92.90  barstatus  1.00 
 MySide L  value1 43.00  Date 1091008.00  Arw_Active_Time 132350.00  LineStart 72.90  LineEnd 92.90  barstatus  1.00 
 MySide L  value1 43.00  Date 1091008.00  Arw_Active_Time 132350.00  LineStart 72.90  LineEnd 92.90  barstatus  1.00 
 MySide L  value1 43.00  Date 1091008.00  Arw_Active_Time 132350.00  LineStart 72.90  LineEnd 92.90  barstatus  1.00 
 MySide L  value1 43.00  Date 1091008.00  Arw_Active_Time 132350.00  LineStart 72.90  LineEnd 92.90  barstatus  1.00 
 MySide L  value1 43.00  Date 1091008.00  Arw_Active_Time 132350.00  LineStart 72.90  LineEnd 92.90  barstatus  1.00 
 MySide L  value1 43.00  Date 1091008.00  Arw_Active_Time 132350.00  LineStart 72.90  LineEnd 92.90  barstatus  2.00 
 MySide L  value1 45.00  Date 1091008.00  Arw_Active_Time 132440.00  LineStart 60.65  LineEnd 80.65  barstatus  1.00 
 MySide L  value1 45.00  Date 1091008.00  Arw_Active_Time 132440.00  LineStart 60.65  LineEnd 80.65  barstatus  1.00 
 MySide L  value1 45.00  Date 1091008.00  Arw_Active_Time 132440.00  LineStart 60.65  LineEnd 80.65  barstatus  1.00 
 MySide L  value1 45.00  Date 1091008.00  Arw_Active_Time 132440.00  LineStart 60.65  LineEnd 80.65  barstatus  1.00 
 MySide L  value1 45.00  Date 1091008.00  Arw_Active_Time 132810.00  LineStart 62.90  LineEnd 82.90  barstatus  2.00

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 08 Oct 2009

A recalculate does not fix the problem. Also switching the chart from chart #2 to chart #1 and back to chart #2 does not fix it. As stated above, I have to turn the study off then back on again and then it starts working properly (but of course only if I reset it to subchart #2).

User avatar
TJ
Posts: 6521
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 957 times
Been thanked: 1883 times

Postby TJ » 08 Oct 2009

I am not sure if I am following...

are you saying you are putting the tl_new_self_s in a function?
and that an indicator that is applied to subchart #2 is calling this function to draw the trendline?

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 08 Oct 2009

No the tl_new_self_s command is in a study. There are no function calls in the study.

The line is a short vertical line to mark a bar in the RSI to match a bar in the price chart (the two lines help me line them up visually). In other words I have two studies running that syc with each other. I drop an arrow to mark where I want the lines. While dropping the arrow I get a cursor across both subcharts and that is the key to the lineup (to the decision as to where to drop the arrow). When the arrow is dropped on the chart and still active and a GV is set then the lines are placed. Once both are placed the arrow is deleted. (cool trick I just started using and as you know I just noticed this vanishing line problem on subchart #2). Once done the lines allow me to refer back. I can clear them both with a global variable set from the database program by issuing a recalculate (such a useful command - use it lots). It is better to have two lines that do not block any more than they need too. This is one example of why I say I often am glad MC is missing a feature because often one can program something that in some ways is better and the missing feature in MC forces it.

Actually the line is normally placed back a few bars on the 10 second bars (at an earlier time) and it just occured to me that I can test to see if the time that line is being placed matches the current bar and if not I probably do not need to be repeatedly using the TL_New_Self_S command until barstatus = 2 since that line deletion problem only occurs on the current bar being built. I am thinking that maybe when the code is putting the line out back a few bars it is putting out more than one line. Probably. Thats funny. I will fix that and see how it runs tomorrow. I should still get the one line at least and if it is the current bar it will keep putting out a new one until barstatus = 2 and the line stops getting deleted with each new tick.

Anyway, I will change that, but that should not cause the problem I am having. Besides the print statement is there proving the command is being executed. As stated earlier the lines appear immediately as I want them to 99% of the time and thus the study appears to be working. In other words the print statement proves the logic is working but it is just that command that is not working (luckily not too often).

User avatar
TJ
Posts: 6521
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 957 times
Been thanked: 1883 times

Postby TJ » 08 Oct 2009

LOL... delete is the culprit. It is deleting the "wrong" drawing object.

I have the same problem too...
I have gone through this with tech support a few times...
but we did not get anywhere. (They don't think there is a problem.)

anyway... I did not have the time (nor the expertize) to get to the bottom of it.
so whenever I do not need a line, I just redraw it to zero.

out of sight, out of mind... LOL

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 09 Oct 2009

Yah it could be that line delete problem but I am not sure at this point because I have a lot less going on in my 10 second bars chart (my one minute bar chart is a lot busier). I have seen lines deleted wrongly on the main chart. I believe it all occurs because the lines keep getting deleted before barstatus = 2. If they would sit down and fix that problem this line deleting problem would vanish. It is all about timing. My theory was that I was deleting the wrong line because I stored the line ID before the barstatus = 2 was reached and another line from another set of code on the same chart is using the same number that I grabbed prematurly. Like if 3 studies (all on the same chart) are creating lines and every single one is deleting them over and over under the hood until barstatus = 2 this is not a good thing. Now if the user is also deleting lines that makes it even more crazy. It is enough to drive someone new to MC and this problem to buy something else.

Anyway, I changed the code here to avoid putting out more than one line by testing barstatus[offset] = 2. I get the offset by doing a binary search for the arrow. So it makes sense that if I am placing the lines back an offset amount then I should be testing the barstatus with offset as well. It is late in the day right now and I will test it tomorrow when the ticks are flying fast and furious.

Redraw to zero is interesting. I could do that since I have a morning cleanup that clears lines prior to the current day.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 09 Oct 2009

Well the barstatus[offset] change worked. If the lines are on the current bar I only get one and if they are back a bit I also only get one.

As far as the known deletion problem I will have to review the studies applied to this chart to see if that is possible. Maybe on the weekend if I get time. The thing is only the vertical RSI line of the pair was missing (never the vertical price line). However it is worth a check since it is annoying having to go in and switch the study off then on plus having to reset it to subchart #2 on top of that. I guess I could program up another keystore button to make it easier.

What is interesting is that pulling the RSI scale up or down does not adjust the vertical lines the way it does on the price chart.

User avatar
TJ
Posts: 6521
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 957 times
Been thanked: 1883 times

Postby TJ » 09 Oct 2009

I meant to do one test... one day when I have the time.

that is to draw arrows, using arw_settext to write the id number with each arrow... then I can track which arrow id is getting deleted.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 09 Oct 2009

I meant to do one test... one day when I have the time.


That test seems like a good idea. You could write them to a print or file just incase you are busy and don't notice it right away.

Anyway, I just learned a few things about EL.

First off, the line is getting deleted. I saw it go out then immediately vanish. It is random of course. It was the RSI line again. Why it picks on this one is a mystery.

Second, testing barstatus[offset] does not work. It compiles but it ignores it and is still testing the barstatus of the current bar. So I have to test time_s[offset] against time_s[0] to determine if the arrow has been placed on a historic bar. Once I get this working properly it means the RSI can be signalled to place the line immediately and once placed the arrow can be deleted. Oh well. Back to the drawing board. I remember there was another one like this. It might be "barnumber" but I need to test it again to be sure.

I can see this is one of those programming days.
Last edited by bowlesj3 on 10 Oct 2009, edited 1 time in total.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 09 Oct 2009

Oh well, the time_s[offset] idea does not work. I still have to keep redrawing tjhe line until barstatus = 2 because it does not matter if I am placing the line back a few offsets. It is still a new line regardless. Sure wish they would fix that problem. it slows down the code too much and on the larger bar sizes such as 1 minute or 5 minutes it creates a problem.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 09 Oct 2009

disregard this post.

I think the problem is actually in the barstatus = 2 command. I suspect it is being turned on too early in the subchart #2 at times and the next tick is deleting the line as normally would only happen if barstatus = 0 or 1. So what I am going to do is store the time_s of the very first TL_new issued and wait until a tick comes in with a time_s greater than this (and at that point I will stop writing out the lines - running the risk of getting two of them out there I guess). We will see if that fixes it. If it runs a few days this way without fail then that maybe confirms this theory.
Last edited by bowlesj3 on 09 Oct 2009, edited 1 time in total.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 09 Oct 2009

Nop, I guess it is the old bug of the line deletes after all. I just saw one of my other studies put a line on the chart and at exactly that time the new study price line was deleted. So I checked out that study which was written before I was aware of this bug and applied your idea of changing the line location to zero rather than deleting it. We will see how it works after a few days/weeks.

Maybe TSS support will read this thread and change EL so it puts the lines out once only and never deletes them on a new tick. However that will create an interesting problem for old code since lots of duplicate lines will end up going out until barstatus = 2. So the solution is create a new command such as TL_Persist Arw_Persist or Text_Persist. That way the users can learn the difference and gradually convert old code to the new command when they have time. If they happen to have code that made the assumption that the lines persisted immediately as I was doing for a long time then all they have to do is switch to the new command and this problem should vanish. However don't assume :-)

For now both studies seem to be working.

User avatar
TJ
Posts: 6521
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 957 times
Been thanked: 1883 times

Postby TJ » 09 Oct 2009

this is an old post... you made a reply as well
http://forum.tssupport.com/viewtopic.php?t=5815

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 10 Oct 2009

The revisit has made the issue more clear to me, make me realize more reasons to request a fix, given me the idea of replacement commands instead of fixing the existing commands and lastly made me realize a way to figure out exactly which commands are creating the problem so if the code is complex (as some of my code is) just maybe one can avoid having to change it should TSS not create the new versions of the commands (or at least confirm the theory as to the senario I describe in my request for new commands post). I will probably eventually do this myself since continuing the TL_new commands to barstatus = 2 could be a challenge.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 22 Oct 2009

The original problem in this thread is verified to actually exist. It is not another bad Line ID deleting the new line created on subchart #2. I made changes to ensure that this was not happening. What is interesting is that every day in the morning (WITHOUT FAIL) I have to turn the study off then on again to get it to start putting out this line. Randomly after that I have to do this status toggle maybe once or twice a day because for some reason the line stops getting put out. Most of the time it works fine.

Something I learned from all this is that the line ID should generally not use intrabarpersist because the TL_new command keeps deleting the line until barstatus = 2. If TSS ever puts in the TL_Persist command I asked for then you would want to put Intrabarpersist on your line ID.

User avatar
TJ
Posts: 6521
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 957 times
Been thanked: 1883 times

Postby TJ » 22 Oct 2009

I have not tried this... what is the purpose to make the line id intrabarpersist?

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 22 Oct 2009

Hi TJ,

Actually I said that it is best (NOT To) use IntraBarPersist (generally). The reason is if MC is deleting the line on the next tick after the TL_New command is issued up until barstatus = 2 then you will want the ID zeroed as well just in case (as I was doing)

1/ you are testing for the ID > 0 to switch to moving the line rather than constantly creating a new one
or
2/ you are testing for the ID > 0 to see if the line is out there before deleting the line.

Before realizing this I tried switching the ID to intrabarpersist one time just to see what would happen and all of a sudden my lines were not getting put on the chart at all. I just figured out why today. My first TL_new would put out the line and I would capture the ID. Then MC deletes the line on the next tick but the intrabarpersist command ensures that the ID still has the value which of course is greater than zero. So my function would think "now that the ID is greater than zero this means I can move the line rather than having to create it". So it would try and move a line that MC has just deleted and I guess it would either move the wrong line or just bypass the command in error. Of course I never did see that line on the chart because the next tick came in fairly fast to trigger the MC deletion before I would notice the line on the chart. I tried it again today and the same thing happened but since I know a lot more about this than I did before it finally hit me as to why I can't use Intrabarpersist on the line IDs. If TSS does put in a TL_Persist command (one that does not delete the line on the next tick) my code would be best changed such that the line ID is also intrabarpersist to match the new behavior.

John.

User avatar
TJ
Posts: 6521
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 957 times
Been thanked: 1883 times

Postby TJ » 22 Oct 2009

come to think of it, I did experiment with intrabarpersist; it was a long time ago, I did not figure out any logical correlation between what I programmed, and the delete behavior... I am still searching.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 22 Oct 2009

This is a bit off topic but I became very aware of it during the process of dealing with the above TL_New problems. What is the theory regarding having to do this when moving trend lines. I seem to remember reading something about this years ago but my recent read through the manuals (like 2/3 years ago) did not mention this. I was getting very whacky line moves then this fixed it perfectly. I was thinking of creating a mini function for this logic.

Code: Select all



   if STARTTIME > tl_getbegintime_s(ID) then
        begin
        value1 = TL_SetEnd_s(ID,ENDDATE,ENDTIME,ENDVALUE);
        value1 = TL_SetBegin_s(ID,STARTDATE,STARTTIME,STARTVALUE);
        end
   else
        begin
        value1 = TL_SetBegin_s(ID,STARTDATE,STARTTIME,STARTVALUE);
        value1 = TL_SetEnd_s(ID,ENDDATE,ENDTIME,ENDVALUE);
        end;



bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 23 Oct 2009

Okay, I just kicked off the first placement of the line on subchart #2 and as usual the line does not appear during the very first placement of the day. However I have more info here to prove that there is a bug.

1/ My print statement which is directly below the line did get printed.
2/ Even more compelling is the fact that the list of drawings found via "right click, format, drawings" shows the line should be there and in addition to this I checked the properties and it says it should be appearing exactly where the print statement says too. In other words the list of drawing tools shows it should be appearing exactly where it is suppose to be appearing. However it is not showing on the chart. There are 3 other lines on the chart and they are all in subchart #1 and they are showing. So my ability to see these other three lines proves I am not blind (YET!). Okay. One more check. It just occured to me that maybe the line is black. However I am not setting it to any color in the study (I just double checked). So the study is placing the line with the default color which is orange basically and the second try does put it out as this color.

So there is no doubt. There is a bug here.

To follow up I kicked off a second attempt after having turned this subchart #2 study off and on again and resetting it to point to subchart #2 as I have to do every single time. This time the line appears (as usual) and the list of lines exactly matches the number of lines on the chart. Color/Colour is orange.

Not the worst bug but a bug none the less. Something for TSS to check eventually.

John.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 23 Oct 2009

This may be my problem. I have noticed that the line placed on subchart #2 does not move when I grab the right hand scale and adjust the RSI scale. I tried a few things and it screwed up the placement of the line and eventually completely locked up windows. I can't afford that so I brought back the workspace from last night's backup and am back to normal again. It is good enough for what I want. It is a vertical line up marker only. It does not need to be accurate relative to the RSI values.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 23 Oct 2009

Regarding the vertical line bug on subchart #2 It just did it again and the line color is orange as per the color setting showing in the list of drawing tools that are suppose to be on that chart. As before the study placed it correctly and the list of drawing tools says it is suppose to be there but it simply is not being displayed buy MultiCharts.

John.

User avatar
TJ
Posts: 6521
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 957 times
Been thanked: 1883 times

Postby TJ » 23 Oct 2009

one quark about lines...

for a horizontal line
the beginning point should be on the left,

for a vertical line
the beginning point should be on the bottom.

if not, sometimes, only sometimes, they can act strangely.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 23 Oct 2009

Thanks TJ.

I will put that change in right now and see what happens.

Otherwise if it does not work I will be writing a sendkeys routine on the weekend to quickly do the on and off and subchart #2 reset.

John.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 23 Oct 2009

Nop. I just made the change, shut down MC and brought it back up and the same thing happens. It is always the subchart #2 lines of the vertical pairs that does not appear (the subchart #1 line is always visible). This time I put out two of them and checked the properties on both of the subchart #2 lines and they were both running bottom to top but unfortunately they are very invisible.

Thanks anyway TJ. I have taken a note of it.

I guess it is a sendkeys night tonight.

User avatar
TJ
Posts: 6521
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 957 times
Been thanked: 1883 times

Postby TJ » 23 Oct 2009

mmm.... I am thinking, if you are re-locating lines in subchart #2,
shouldn't you be using the keywords
TL_SetBegin_Self_s and
TL_SetEnd_Self_s ?


I afraid every time you re-locate a line, the line got re-drawn in the main chart.
and... because the aforementioned keywords do not exist... your hands are tied.

TS handle this differently... they don't have the _Self keywords.

In TS,
if you apply the indicator to the main chart... it draws in main chart,
if you apply the indicator to subchart #2... it draws in subchart #2,
i.e. you cannot use ONE indicator to draw lines on both the main chart AND subchart at the same time.
i.e. if you want an indicator to display lines in more than one subcharts, you have to apply an indicator to each subchart section.

:-)

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 23 Oct 2009

Actually this is interesting. The following is my command to create the line in subchart #2.

Code: Select all

LVL_ID[X] = tl_new_self_s(Date,Arw_Active_Time,LineStart,Date,Arw_Active_Time,LineEnd);



This gets executed until barstatus = 2 and that is the last time it gets executed for each placement of the line. The line normally does not get moved. The above command is the command that does not work when I first restart MC (and sometiimes it stops randomly during the day maybe 2 or 3 times).

However you are correct TJ. If the line gets moved it can be moved forward in time or backward in time (I actually manually move a line in the subchart #1 and that new location is transferred through a GV to the subchart #2 study and it executes the move commands to make sure that the subchart #2 vertical line is properly lined up with the subchart #1 vertical line). However the move commands are not self_s but the regular commands and they work fine. These are the commands.

Code: Select all


if Arw_Active_Status = 3 then
    begin
    if Arw_Active_Time > tl_getbegintime_s(LVL_ID[X]) then
        begin
        value1 = TL_SetEnd_s(LVL_ID[X],Date,Arw_Active_Time,LineEnd);
        value1 = TL_SetBegin_s(LVL_ID[X],Date,Arw_Active_Time,LineStart);
        end
    else
        begin
        value1 = TL_SetBegin_s(LVL_ID[X],Date,Arw_Active_Time,LineStart);
        value1 = TL_SetEnd_s(LVL_ID[X],Date,Arw_Active_Time,LineEnd);
        end;
    value1 = GV_SetNamedInt("TW_ArrowStatus",0);
    Playsound("C:\WINDOWS\Media\Ringout.wav");
    end;


So I guess I will change the commands to make it correct in theory but these commands still work perfectly.

I have a theory now. Some of the subchart #2 studies do not hold their subchart #2 designation when I turn them off then back on. They keep reverting back to subchart #1. Not all of them but it seems 50% of them and at least one other user has reported this. Maybe when I restart MC this study gets confused and is actually putting the line on subchart #1 even though it shows in the list of studies as being in subchart #2 (and it also shows in the list of drawings that the line is in subchart #2 as well). Maybe in actual fact it has put it in subchart #1 and I have to reset it to get it to realize it should go in subchart #2. The only trouble here is that it is an RSI value and it is way way way way down in subchart #1 that I have to go to find out if this line is actually there (I tried looking once and it takes a long time. It is not worth looking for it).

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 23 Oct 2009

We learn something every day.

I just checked. There is no TL_SetBegin_Self_S or TL_SetEnd_Self_S. I have the correct commands after all. I guess that is why they work perfectly.

:-)

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 26 Oct 2009

I managed to get the vertical lines to appear on the RSI. I had to set the Scale Type to "User Defined" and use the values Maximum 100 and Minimum 5. Linear has to be used as well. Every other combination of settings for Scale Type failes to show the lines.

Of note, Somehow I got the Subchart #2 to stick when I toggle the study off then on again.

Last but not least I shut MC down and restarted it and the lines continued to appear without my having to turn the study off and on again.

I guess this sets this one to rest. A tough one. I need a break :-( and a reward :-)
Last edited by bowlesj3 on 26 Oct 2009, edited 5 times in total.

User avatar
TJ
Posts: 6521
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 957 times
Been thanked: 1883 times

Postby TJ » 26 Oct 2009

one quark about lines...

for a horizontal line
the beginning point should be on the left,

for a vertical line
the beginning point should be on the bottom.

if not, sometimes, only sometimes, they can act strangely.



for a vertical line, you might try this trick:


TL_NEW(D, T, H, D, T+1, L);



.
Last edited by TJ on 26 Oct 2009, edited 1 time in total.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 26 Oct 2009

What does this do TJ? I would think that it puts the line on an angle.

User avatar
TJ
Posts: 6521
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 957 times
Been thanked: 1883 times

Postby TJ » 26 Oct 2009

What does this do TJ? I would think that it puts the line on an angle.



because the +1 is so small a value... it would be inside the bar increment, therefore MC would round it down to fit the time frame.

The line would appear vertical.


this is useful when you need to draw a vertical line with the beginning point higher than the end point.

User avatar
TJ
Posts: 6521
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 957 times
Been thanked: 1883 times

Postby TJ » 26 Oct 2009

I managed to get the vertical lines to appear on the RSI. I had to set the Scale Type to "User Defined" and use the values Maximum 100 and Minimum 5. Linear has to be used as well. Every other combination of settings for Scale Type failes to show the lines.

Of note, Somehow I got the Subchart #2 to stick when I toggle the study off then on again.

Last but not least I shut MC down and restarted it and the lines continued to appear without my having to turn the study off and on again.

I guess this sets this one to rest. A tough one. I need a break :-( and a reward :-)



I have vertical line in my RSI type indicators as well.
I am using plots (set to bar high/low)... because I do not need to move them.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 26 Oct 2009

I use plots on one of my RSI charts. The plots run horizontally. I used plots because I could not get the lines to work at that time. I also use plots on all my chart sizes to mark the even 10 units in different color coding.

How old is RSI?

User avatar
RobotMan
Posts: 375
Joined: 12 Jul 2006
Location: Los Altos, California, USA
Has thanked: 31 times
Been thanked: 12 times
Contact:

Postby RobotMan » 26 Oct 2009

Hi guys,

I don't know if this helps, but...

I tried playing around with session breaks in sub-charts a while back.
See: http://forum.tssupport.com/viewtopic.php?t=5560

I found that just inserting the code as an indicator, into a subchart would give a vertical line at the session breaks. I just used "H" and "L" as the start and end point and then extended left and right. (see code in the post)

Maybe you could play around with that idea and get it to plot a Vertical TL where you want it. I dunno.

I also discovered "FindBar(Date,Time)" which tells you the bars back from CurrentBar. So there's that. Of course it is still limited to bars that don't reference seconds and I never played around with it.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 27 Oct 2009

Hi Bob,

In my case I am putting a short little vertical line below price in subchart #1 and a second vertical line below RSI in subchart #2 (below if I am going short and above if I am going long). Extending the vertical line would block the price bars or the RSI. The manual scale settings I mention above are close enough for a visual lineup (the vertical line comes in just above or below the RSI). If I wanted the subchart #2 line to exactly match the RSI some how I am not sure how I would do it. I might have to set my RSI study so scale exactly as this vertical line study is scaled (both manually set - and never touch the RSI subchart ever). However I won't bother figuring that out until I need it (if ever).

Thanks for pointing out this function Bob. Looking at it gave me an idea to improve a similar type of function I am using which I wrote. For the findBar function I wrote a binary search function (one for 1 minute bars and one for 10 second bars). Binary is the fastest search and if a bar is missing it will report it. There is a post that shows the code (it's code is much larger than the findbar code and can search your whole chart if used properly with a high maxbarsback setting). Just search for binary if you want to use it. It gives you the backward square bracket offset of that bar. It has occured to me that if the maxbarsback setting is too low it will probably force a recalculate the first few tries to find a bar farther back. I will probably change it very soon to report this (with an alert statement and a print to file statement) so I can adjust my studies accordingly afterwords. Not making this adjustment could cause problems in some studies and MC does not give a notice on this recalculate.

John.
Last edited by bowlesj3 on 27 Oct 2009, edited 3 times in total.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 27 Oct 2009

For the purpose of getting your lines to line up in subchart #2 (across studies) my last theory is exactly correct. Set your RSI scale to manual (max 100 and min 0) then set your other studies using this subchart #2 exactly the same way and any lines drawn on the other studies will exactly match the RSI study's scale.

If you click and drag the right hand scale on the RSI it will force a manual setting on that study but it will not be a perfectly 100/0 scale unless you are lucky (or unless you put lines out with the other study as a guide).

Okay so now this one is fully put to rest. Now all we need is a way to control all this with EL code (or maybe a way to lock the manual setting so the user can not change it accidently). Other than this just put your lines in the RSI study (all in one study for subchart #2).

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 27 Oct 2009

What is interesting is if you set both the RSI study to scale off screen and the second study (the vertical line study) to scale off screen, it not only screws up the placement of lines on the 2nd study which is based off subchart #2 but it also screws up the line placement of the study which puts the vertical line on subchart #1 as well. Strange! TSS needs to do some work here or maybe put out something to explain all this better. Enough for curiosity.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 27 Oct 2009

Here is another solution using the screen scaling setting rather than user defined scale settings (assuming for some reason you want two separate studies defined in the subchart #2 area of your chart). The two studies need to have a plot 100 and plot zero as shown below and they have to have the same margin settings as well. This forces them to line up so you can see the lines.

Code: Select all

MyRSI = RSI(Close,14);
Plot2( 100, "100" ) ;
Plot3( 0, "0" ) ;


However you can not drag the scale(s) since one or both will go manual when you do and they will not be lined up.

So in my case I am just going to combine the regular RSI study and this new study now that I have it fully working. The problem will be solved at that point and I can drag the scale I would assume.

I guess to avoid these scale problems subchart #2 (#3 etc) should only have one study since its scale is based upon a plot calculated off of price. Subchart #1 can have more than one study since its scale is normally calculated off of price which is not calculated inside a study.

User avatar
RobotMan
Posts: 375
Joined: 12 Jul 2006
Location: Los Altos, California, USA
Has thanked: 31 times
Been thanked: 12 times
Contact:

Postby RobotMan » 27 Oct 2009

Hi John,

Yeah the only way I can get two indicators to line up in a subchart is to use some contrived stuff.
See: http://forum.tssupport.com/viewtopic.php?t=5889

or, kinda like you are doing, write all the code in one dedicated indicator.

Another way, if you ar not using an oscilator that stays between an upper an lower limit, is to use the "invisible" plot style and plot an inverse of the indicator and then just render it invisible. Sometimes, if there are several plots you might have to do a MaxList or MinList type of filter, use the inverse, and then set that value as invisible. What happens is the "zero" (or 50%) line alway stays in the middle and any other indicator you place in the subchart using the same type of shenanigans will also have the same zero or 50% line. Of course they will have different scaling, which, sometimes is just unsolvable. (ie: a MACD that is maxed out at .056 and a stochastic that is maxed out at 100; if they had the same scale, you wouldn't see the MACD)

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 28 Oct 2009

Thanks Bob,

I am going to read your post a bit later (I am in a bit rushed getting ready for trading). For now I have found a very good reason to keep my studies separate. I have three studies in total using subchart #2. One uses a recalculate often to clear the lines and the other one does not and I do not want any of the other two subchart #2 studies recalculating until I decide they should. For for me it seems the best method is to set them all to scale manually at 100 & 0 with a bit of lower margin since I can't see the zero line without it. Once set I just never touch them. Putting plots on 0 and 100 might be a good idea so I can visually see if they have gone out of line with each other. I suppose it will not slow things down much.

John.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 28 Oct 2009

The stuff you describe Bob sounds pretty complex. I am glad my requirement is much simpler and working okay.

Thanks again,
John.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 04 Nov 2009

Regarding these two solutions too the "Subchart #2 trend lines not appearing" problem

#1 Screen scaling setting with highest and lowest plots included in all studies that require lines on the chart (4 posts above).

#2 Set your RSI scale to manual (max 100 and min 0) then set your other studies using this subchart #2 exactly the same way (6 posts above)

It seems that the best option of the two is the second. The reason is that when the studies get out of line you can see it because the extreme high and low plots will be out of whack. A simple double click on the right hand scale brings them back in line.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 05 Nov 2009

As a little final note on the disappearing lines, at times both lines would disappear and the issue in the thread below explains why. In short, the arrow time was coming back as -1 even though the ID was found for the arrow. Both vertical lines were (sometimes) being placed at a time of -1 (out of sight of course). Being very infrequent and random it took a while for it to bug me enough to cause me to bite the bullet and take the time to find it and develop the code to work around it.

http://forum.tssupport.com/viewtopic.ph ... 847237f79e

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 26 Nov 2009

Regarding the statement I made below which appears 2 posts up,

It seems that the best option of the two is the second. The reason is that when the studies get out of line you can see it because the extreme high and low plots will be out of whack. A simple double click on the right hand scale brings them back in line.


Way back, Marina and a programmer looked at my RSI subchart and saw that the dotted lines for (10,20,30 etc) go out of line with the plots I put in the study to colour code the even 10 lines (10,20,30, etc). It turns out that the double click mentioned in the quote above also fixes this up (in other words the scale gets out of line). When MC is started the scale seems to often go out. I am not sure if this has been fixed at this point but I thought I would pass on this insite. They said it was a new bug so I guess that means that MC should really retain these scales on startup and not let them slip out of line if the trader does not manually adjust them during the day.

bowlesj3
Posts: 1977
Joined: 21 Jul 2007
Has thanked: 155 times
Been thanked: 395 times

Postby bowlesj3 » 29 Nov 2009

Slight correction to the above post.

I have to squeeze the scale by dragging it down then double click.

double click alone does not work.


Return to “MultiCharts”