Is this a MC bug? or is my coding wrong?
Would some experts please teach me how to DELETE.
I wrote a little indicator. It plants a flag at Key Reversal points.
(code attached)
When a new Key Reversal is made, it will delete the old one. (within the lookback bars)
However, while the indicator is deleting the old Key Reserval flag, it also deletes other drawing objects on the chart.
I have attached an illustration.
YOU CAN ONLY see this happen in real time... because the indicator will plant a flag, then removes it as the market makes new key reversals.
Your comment is appreciated.
MC bug? or my coding error?
-
TJ
- Posts: 7742
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2222 times
MC bug? or my coding error?
- Attachments
-
- KeyReversalFlag.txt
- (1.64 KiB) Downloaded 442 times
-
- MysteriousDeletes.gif
- (92.14 KiB) Downloaded 322 times
Last edited by TJ on 05 Dec 2008, edited 3 times in total.
-
TJ
- Posts: 7742
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2222 times
can someone give this a try?
Maybe this is a MC bug?
I have included a test_marker here. You can see it being mysteriously deleted as the Key Reversal indicator makes a new flag.
Maybe this is a MC bug?
I have included a test_marker here. You can see it being mysteriously deleted as the Key Reversal indicator makes a new flag.
- Attachments
-
- !!_test_marker.txt
- (223 Bytes) Downloaded 424 times
New TL each tick.
I have improved this a few times. Its a bit long since it impacts the way I use MC significantly and could be better. Maybe TS-Support can use it to get ideas for improving their version of EL.
For anyone new to MC I should note that the tests I describe below were all done on MC 2.1.999.999 so it would be a good idea to do these tests before you do a lot of programming on any future releases just to be sure you don't get into a position where you wish you had have programmed it differently as I currently am. Amazingly my code works and I am taking the "if it isn't broken don't fix it" approach to trading more and programming less.
I have noticed that arrows, text and trend lines all get deleted automatically by MC on each new tick and are put out fresh again by the (TL_New/Text_New/Arw_New) command and this automatic deletion does not stop until the last tick of the bar (just to be clear, it does not restart the deleting after that point). So if you were to print the ID coming from the TL_New command on every single tick it will potentially be a new ID number if other parts of the study (or another study running on the same chart) are also generating trend lines intermittently during those ticks.
You can prove this is happening by trying to manually move a new (text,arrow,trendline) before the last tick of the bar occurs. You will find it keeps putting it back in the original location then finally at the end of the bar you can manually move it to another location and it will stay there. Again what is happening here is, before the end of the bar on each new tick MC deletes the text/arrow/trendline you manually moved and it redraws a new one in the original location when it hits the (TL_New/Text_New/Arw_New) command again. I have a study where I move things like this. I have a sound go off which notifies me I can move the items it creates. The other option of course is to not put the text (or whatever) out until barstatus = 2 which indicates the last tick of the bar and include the sound to let you know it is finally out there. I have never put anything out on any bar size other than 1-minute bars and 10 second bars (not anything I wanted to move manually that is). Waiting until the end of a 5-minute bar could be annoying.
Another way to prove MC is deleting objects on each new tick would be to force the TL_new command to only execute once by using a GV, which you can trust to hold the value. You would store (in the GV) information that tells MC that the TL_Command should not execute a second time. You should run this test with barstatus such that it does not do it on the last tick. The object may flash on the screen and be gone on the next tick before you blink an eye. Once this test is done then force the TL_new command to execute on the last tick using barstatus. The object should stay out there. You might want to retry the test with text and arrows to verify they act the same.
Using Intrabarpersist on the ID you get from the (TL_New/Text_New/Arw_New) command does not help. I know of no solution to this. So what I think is happening FJ is your delete command if it occurs intrabar is finding the wrong one and thus deleting something you don't want it to delete (I have had it happen also). You need to capture the final value using barstatus = 2 to time it properly. Only then can you be sure that you have the correct ID for later deletion if you want. So as far as I am concerned this is a bug in EL (not sure if it is a bug in MC). Objects should not be deleted on each new tick. Regarding variables, it would be nice if MC had an option to make intrabarpersist default of On so that the users could truly trust them to hold their values across ticks within the same bar. It needs to be an option because it could screw up existing code.
Final comment to TS-Support. I have been programming a long time and this problem makes EL harder than it should be in my opinion. So the New object commands also need an intrabarpersist. If this is too hard then programming manuals should clearly state the problem and provide tests like the above so the user has it clear in their head before they code. I would estimate it took me about three times as long to get my code to work than it should have since I was not aware of this EL hidden twist. I think it should be an up front section of EL anomalies to be aware of before you start. I have programmed 11 languages in total over the years. EL is the only one of those that zeros things (or deletes objects) unexpectedly like this. I often wish I knew the thinking or sequence of events that created something like this and even more so why it still exists. However, I try not to scratch my head too much about it for if I did I Might loose too much hair
John.
For anyone new to MC I should note that the tests I describe below were all done on MC 2.1.999.999 so it would be a good idea to do these tests before you do a lot of programming on any future releases just to be sure you don't get into a position where you wish you had have programmed it differently as I currently am. Amazingly my code works and I am taking the "if it isn't broken don't fix it" approach to trading more and programming less.
I have noticed that arrows, text and trend lines all get deleted automatically by MC on each new tick and are put out fresh again by the (TL_New/Text_New/Arw_New) command and this automatic deletion does not stop until the last tick of the bar (just to be clear, it does not restart the deleting after that point). So if you were to print the ID coming from the TL_New command on every single tick it will potentially be a new ID number if other parts of the study (or another study running on the same chart) are also generating trend lines intermittently during those ticks.
You can prove this is happening by trying to manually move a new (text,arrow,trendline) before the last tick of the bar occurs. You will find it keeps putting it back in the original location then finally at the end of the bar you can manually move it to another location and it will stay there. Again what is happening here is, before the end of the bar on each new tick MC deletes the text/arrow/trendline you manually moved and it redraws a new one in the original location when it hits the (TL_New/Text_New/Arw_New) command again. I have a study where I move things like this. I have a sound go off which notifies me I can move the items it creates. The other option of course is to not put the text (or whatever) out until barstatus = 2 which indicates the last tick of the bar and include the sound to let you know it is finally out there. I have never put anything out on any bar size other than 1-minute bars and 10 second bars (not anything I wanted to move manually that is). Waiting until the end of a 5-minute bar could be annoying.
Another way to prove MC is deleting objects on each new tick would be to force the TL_new command to only execute once by using a GV, which you can trust to hold the value. You would store (in the GV) information that tells MC that the TL_Command should not execute a second time. You should run this test with barstatus such that it does not do it on the last tick. The object may flash on the screen and be gone on the next tick before you blink an eye. Once this test is done then force the TL_new command to execute on the last tick using barstatus. The object should stay out there. You might want to retry the test with text and arrows to verify they act the same.
Using Intrabarpersist on the ID you get from the (TL_New/Text_New/Arw_New) command does not help. I know of no solution to this. So what I think is happening FJ is your delete command if it occurs intrabar is finding the wrong one and thus deleting something you don't want it to delete (I have had it happen also). You need to capture the final value using barstatus = 2 to time it properly. Only then can you be sure that you have the correct ID for later deletion if you want. So as far as I am concerned this is a bug in EL (not sure if it is a bug in MC). Objects should not be deleted on each new tick. Regarding variables, it would be nice if MC had an option to make intrabarpersist default of On so that the users could truly trust them to hold their values across ticks within the same bar. It needs to be an option because it could screw up existing code.
Final comment to TS-Support. I have been programming a long time and this problem makes EL harder than it should be in my opinion. So the New object commands also need an intrabarpersist. If this is too hard then programming manuals should clearly state the problem and provide tests like the above so the user has it clear in their head before they code. I would estimate it took me about three times as long to get my code to work than it should have since I was not aware of this EL hidden twist. I think it should be an up front section of EL anomalies to be aware of before you start. I have programmed 11 languages in total over the years. EL is the only one of those that zeros things (or deletes objects) unexpectedly like this. I often wish I knew the thinking or sequence of events that created something like this and even more so why it still exists. However, I try not to scratch my head too much about it for if I did I Might loose too much hair
John.
-
Marina Pashkova
- Posts: 2758
- Joined: 27 Jul 2007
Re: MC bug? or my coding error?
Hi TJ,Is this a MC bug? or is my coding wrong?
Would some experts please teach me how to DELETE.
I wrote a little indicator. It plants a flag at Key Reversal points.
(code attached)
When a new Key Reversal is made, it will delete the old one. (within the lookback bars)
However, while the indicator is deleting the old Key Reserval flag, it also deletes other drawing objects on the chart.
I have attached an illustration.
YOU CAN ONLY see this happen in real time... because the indicator will plant a flag, then removes it as the market makes new key reversals.
Your comment is appreciated.
This isn't a bug. Below, you will find two possible solutions to your current problem.
----
1. You can have your indicators calculated only on Close of each bar. To achieve that, simply disable the 'update on every tick' option.
----
or
----
2) Use intrabarpersist variables as variables for drawings's IDs. You would also need to modify the section of the code that deletes the drawings:
----
Code: Select all
var:
intrabarpersist id_tl(-1);
if id_tl > 0 then
begin
tl_delete(id_tl);
id_tl = -1;
end;
The second option might not help, if the condition for creating a drawing is met inside the bar but is not met on bar close. To eliminate such a possibility, the code must be modified:
Code: Select all
var:
intrabarpersist id_tl(-1),
id_tmp(-1);
// reset temp ID
id_tmp = -1;
if id_tl > 0 then
begin
tl_delete(id_tl);
id_tl = -1;
end;
id_tmp = tl_new_s(d,time_s,c,d[1],time_s[1],c[1]);
// tl_setcolor(id_tmp, black);
// ...
// If bar closed then id_tl = id_tmp
if barstatus = 2 then id_tl = id_tmp;