Draw Objects - Tick Charts

[NinjaTrader_Bertrand]

Thanks for the feedback and report kinderlich - we'll look into matters and update you with our findings.

[NinjaTrader_Bertrand]

kinderlich, unfortunately this outcome is expected behavior - we've added your input to our feedback list.

[mjc4118]

I wanted to add to this thread as I have made some observations that may effect this. Basically it comes down to "user" expectation. I have posted a screen shot that demonstrates my comments...

earlier I stated:
I have spent a little more time on this and honestly believe I have truly Identified the issue. I believe that you should have been able to identify this also, and I think it also falls into the realm of "bug issue". It appears that the Actual Saving and loading the drawing object data on the charts is not the issue. The issue is in the actual calculation of the Anchor point for the right anchor of the draw objects.

I believe that this is the case. In the attached screen shot I drew an object and looked at the draw properties for that object IMMEDIATELY after drawing and noticed a discrepancy.

On the CHART...after drawing the objects end point is "9:09:20" ...in the properties dialog the "calculated" end point for the object is "10:42.46" as you can see in the property dialog...

The USER expectation would be that this object was drawn with a right anchor at "9:09:20" because that is what appears on the chart when I draw the object and that is what the software is visually telling me at the time I draw it ...So unless I go look in properties I would never know that the endpoint was anything other than "9:09:20" and would not be aware of the discrepancy

Now If exit ninja and restart it ..or simply disconnect ..and reconnect after 10 or 20 minutes ... then the object is redrawn with the endpoint from your properties dialog..."10:42.46"

The issue is that if I wanted the box to end at "10:42.46" then I would have drawn it so that it ended at "10:42.46" on the chart. I did not. I drew the object so that it ended AT "9:09:20" AN YOU calculated THE VALUE "10:42.46" and stored that in your properties. So .. basically ...NinjaTrader decided based on some algrythim that the user knows nothing about...that the user did not want the box to terminate/anchor at the point displayed on the chart..but some other calculated value that the user knows nothing about.

Humm.... I do not think that that is correct way to handle it. Either draw the object in this case so that the values match... (not preferred if you do not let me anchor my box where I want it...)

Or ..preferred ...simply calculate the correct value of "9:09:20" in the properties for the anchor point and be done with it... because unless you store this value ...and not the value you are currently calculating then ... it is not right.

And..in case anyone wants to know ..this is NOT a multi-time frame object and ONLY appears on the 250 tick chart displayed with a single data-series...so there is no reason to come up with any other time value based on the object ..or the data series on the chart.

Thanks..
Mark

[NinjaTrader_JoshP]

Mark,

This is simply the issue of drawing into the future. When you try to draw an object into the future, since the future x-axis timeline is not known at that point in time, it is extrapolated and guessed. This is especially true when you use tick charts. There is no way NT could reasonable guess how many tick bars it would take to go from 9:00 to 9:10. It could be 100 bars or 1000 bars. Because of this ambiguity, as new bars start filling in, the x-axis will update its extrapolation to match up with the data that ended up presenting itself. If more bars were added than the original extrapolation alloted slots for, then the whole x-axis will need to be updated with whole new extrapolations. As the x-axis is updated with these new extrapolations, the draw object will not follow this. The draw object will remain static with whatever the first extrapolated timestamp was when drawn into the future. The last thing a user would want is the object to constantly extend back and forth depending on how the extrapolation turned out to be as more bars filled in.

[mjc4118]

Well ...a few points...in 6.5 this was really a non-issue... so this horrid behavior is new to 7.0. And yes, horrid is a carefully chosen word here.

It makes considerable work for users especially with trend lines. And if you traded, you would know how important those trend lines are.

I think the solution is pretty easy .. Simply anchor it to the correct time.. and if that time passes stop adjusting it... I personally would rather see it jump back and forth as you say and KNOW that it is not "fixed"

But as far as it jumping back and forth, I think that with the proper logic that that would not happen in a drastic manner if it is in the future ...display it to the right of the active candle...extrapolate out how many bars leaving the anchor in that spot on the "right" of the active bar would be and simply calculate the time correctly once that point on the chart is reached... You are NOT moving the object now when the live chart is displayed... but you are moving it when I reload ...MOVING it to the CORRECT anchor time but moving it none the less.. Because visually the shape of the object changes on reload.

If the object is 4 bars Space Worth ahead of the CurrentBar then after 4 more bars have painted and closed ... recalculate that anchor value. To do otherwiese is to prend that you are displaying and saving those anchor points in any logical manner...because the application is misleading the usern the way the draw object represents itself as it is displayed on the screen...compared to the change ..in visual representation on reload.
What you do not seem to understand that on tick and volume charts ..time has NO relevance. and the fact it means something to you ..in the need to anchor your drawing objects is really an issue that you have to figure out how to deal with. If you poll tick and volume chart users then they will undoubtedly agree with me on the point of recalculating the anchor time value after x bars has passed so that the object retains it shape/visual representation.

It just seems like you folks do not want to take the time to write the code to fix the problem and that you believe that the current solution is effective. It is not. I purchased Ninjatrader lifetime 6.5 License and one of the reasons was because I really liked your chart markup abilities...now you have taken the effectiveness of that away.That is not fair. Granted you have given us some cool stuff in return but If I do not have proper trend lines I do not make $$ so I spend countless hours adjusting them when I reopen my charts... I was simply leaving my charts open 24/7 .so they would not redraw . In another thread I was told ..that is not suggested..by one of your staff ...so now I shut them down at night. So ..every AM I spend 30 minutes redrawing trend lines because they have moved. I cannot use RAY..even though it has two anchor points in the past .. so Please think about the logic on updating those draw objects correctly instead of in this current inaccurate manner.

[TAJTrades]

mjc4118,

I have run into the same issue: http://www.ninjatrader.com/support/f...ad.php?t=34176

As of now this is a show stopper for me and NT7. Somethings I just don't understand.

[NinjaTrader_JoshP]

mjc4118,

Not sure why you feel 6.5 behaves any differently. It is exactly the same extrapolation concept for the draw objects. Please see the 3 attached screenshots for 6.5. Exactly the same behavior. The only difference from 6.5 and 7 here is that 6.5 does not show you extrapolated timestamps on the x-axis which is a step backwards from NT7. In 6.5 all future time slots are shown on the x-axis as the exact same timestamp as the last shown timestamp while NT7 actually tries to show you what it thinks it might be.

As far as objects moving back and forth constantly as data fills in; it may be what you would expect, but not necessarily what others expect. I for one definitely would not want my objects moving up and down the chart as I am trading because that completely skews with the relationship I am trying to highlight.

You can't just count "bar spacing" because spacing is irrelevant since objects are not and cannot be tied to bars. Objects are tied to timestamps. Trying to tie it to bars completely negates the snap mode options along with non-equidistant chart options. This has nothing to do with whether or not tick/volume charts rely on timestamps, but everything to do with general chart concepts.

[mjc4118]

Not sure why you feel 6.5 behaves any differently. It is exactly the same extrapolation concept for the draw objects. Please see the 3 attached screenshots for 6.5. Exactly the same behavior.

well, I worked w/ 6.5 for a year and never experienced "moving" (or visual alteration) of objects until I started using 7.0. you logic may be exactly the same. Your implementation on the new charts is not based on the results i get. The bars on the right or the time line is/ are calculated differently in 7.0

.. and if everything is the same then your previous chart control was more conducive to better results in 6.5

I for one definitely would not want my objects moving up and down the chart as I am trading because that completely skews with the relationship I am trying to highlight.

realistically ..if you could anchor them to bars then they would not move. ever.

You can't just count "bar spacing" because spacing is irrelevant since objects are not and cannot be tied to bars. Objects are tied to timestamps. Trying to tie it to bars completely negates the snap mode options along with non-equidistant chart options. This has nothing to do with whether or not tick/volume charts rely on timestamps, but everything to do with general chart concepts.

And that is fine. And I understand your logic...but even you agree based on your posts .. that there are difficulties with calculating time for a bar in the future on non-time based charts...all we are asking you to do is to update the anchors time stamp for the object when that "imaginary bar" has closed. It is simple in concept. It may be harder to apply but where you are wrong or not clear is that when trading tick and volume you seem to believe that time has some meaning ... The truth of the matter is that time means something to NinjaTrader ...it means nothing to Tick and Volume chart traders ..trying to fix us to a time that is calculated ...and NOT RECALCULATED on bar close for the "imaginary" bar is a clear case of round peg/square hole. The logic simply does not fit.

And When my trend lines are attached to time ..that is extrapolated and not actual all of my trend lines and object become useless junk ...

How many people out there use tick and volume charts.. ?? What do they think about how these object end time stamps are calculated?

[Light]

Possible solution

Guys, why not save the positions in terms of bar index on non-equidistant charts (e.g., standard tick charts, if I have the nomenclature right)? The bar index is known on both currently-forming and future bars. (ChartControl.LastBarPainted correctly counts bars into the future.) Why not use that for anchor points on most chart types? (I suppose because the equidistant option makes it impossible.)

Assuming there is a good reason why not, here's another option:

If I understand correctly, and it's not a bug, the problem can only occur if the right-most anchor point is on a currently-forming (opened but not closed) bar, or on a not-yet opened "future" bar. In the first case, NT could simply save the anchor point with a time stamp at the moment the object was drawn. Then when the chart is redrawn, place the anchor on the first bar whose time stamp is >= the draw time. Only the bar that was forming at the draw time will fit that criteria, and thus the object will anchor on exactly the right bar.

Future-bar anchor points using time stamps are more complex. If the bars progress up to or beyond the future anchor point prior to chart close, the time stamp would need to be changed to the time stamp of the bar at the anchor point when the chart was closed. Then when reopened, the anchor point would be the same. If bars-in-progress do not reach the right-most anchor point prior to chart close, then the "future" anchor point time stamp should be saved as the close of the last bar on chart. When reopened, chart objects in the future would end on the previously last known bar.

However, I would still suggest using bar index on standard chart types, not time stamps. But I am sure you guys thought of such things long ago and you are taking the best path under the circumstances...

Thanks for your help. NT7 is terrific! I hope the official release is soon...

Light

[mjc4118]

Also ... when the object is drawn ORIGINALLY the end point/anchor on the time line does not match your end point stored in your data. If it did we probably would not be having this conversation. If you look at thge last image i posted the two time stamps are different...from the cross-hair/visual anchor end point of the drawing object and the data in the property dialog...I simply cannot fathom any logic for this to be the case not mater the "reasoning" use the time stamp from the chart time line when the user draws the box ..problem solved...because at least there is logic in how the time stamp was chosen...

[mjc4118]

Then when the chart is redrawn, place the anchor on the first bar whose time stamp is >= the draw time. Only the bar that was forming at the draw time will fit that criteria, and thus the object will anchor on exactly the right bar.
Light

Would not work with trend lines ... I wish it would..
and I also agree..many great improvements in 7.0

[Light]

Thanks mjc. Lots of kudos for NT7 here too.

I am afraid I don't follow. As far as I understand, that idea would work as described. However, a better solution might be to record the absolute position of the first anchor point only, and the second relative to the first in terms of numbers of bars away (to the left or right). That way the first point could be anchored with a time-stamp and the second could be extrapolated from there. This would be a better solution for trendlines drawn into the future, since the forward-most data point would not need to be recorded as a time stamp. The trendline could be redrawn from the first anchor point only (which would need to be on current bars).

These are fairly obvious ideas, ones they may well have considered and rejected for other reasons. But it's possible they simply haven't had time to explore all options. Still, it's important that trendlines be precise, and save that way -- at least on standard chart types.

Best wishes,

Light

[kinderlich]

Josh, when you draw an object into the future, visually you are defining the object by the # of bars, not the future time. So if you specify the right side of the object with a future 'extrapolated' time stamp in the save representation, on reload of the workspace the objects will be distorted. I'm forced to redraw all objects that have right side in the future after a reload of a workspace. Which is a ridiculous situation. Why can't this problem be fixed? It seems a conceptual problem. You don't conceptually have the correct save representation.

[NinjaTrader_JoshP]

Objects in the future are all time based anchors. If your chart is set to equidistant it will appear to be anchored to bars, but it is not. It is anchored to time. Concept of anchoring to bars is not feasible as it does not work in non-equidistant charts or multi-series charts.