How do I tell text size?

[ETFVoyageur]

I have a multi-line string I am going to use Draw.Text(...) to display. How do I know how big the resulting display will be, so that I can position it correctly?

--EV

[NinjaTrader_DaveI]

Would the font size suffice in this case? If so, you can obtain it via the .Font.Size property, as below:

 myText = Draw.TextFixed(this, "tag1", "my text", TextPosition.Center);

Print(myText.Font.Size);]

This will work with Draw.Text, as well.

[ETFVoyageur]

Would the font size suffice in this case? If so, you can obtain it via the .Font.Size property, as below:

 myText = Draw.TextFixed(this, "tag1", "my text", TextPosition.Center);

Print(myText.Font.Size);]

This will work with Draw.Text, as well.

That's a definite "maybe". I'll have to think about it. At first glance it looks non-trivial use what Microsoft provided to do NinjaScript drawing.

It would be really nice if the Text object just had the appropriate property or properties in units that work with the Draw calls.

--EV

[koganam]

That's a definite "maybe". I'll have to think about it. At first glance it looks non-trivial use what Microsoft provided to do NinjaScript drawing.

It would be really nice if the Text object just had the appropriate property or properties in units that work with the Draw calls.

--EV

You would always need to calculate the spacing based on font size if you want dynamic scaling of the text.

ref: http://ninjatrader.com/support/forum...ad.php?t=77140

[NinjaTrader_DaveI]

Another quick note -- the value held in .Font.Size is quoted in DIP (device independent pixels).

[ETFVoyageur]

What I care about is dynamically placing the text block so it does not obscure anything else. To do that reliably I need to now its size. I still do not understand how to do that.

• NinjaTrader_Dave suggests using the Text object's font.size property
• I do not see how to get a Text object prior to drawing, which is what I need in order to Draw at the correct location. The only way I see to get one is the result of a Draw operation. By then it is too late unless the idea is to Draw, cancel, and Draw again. Is that really what is being suggested?
• The documentation says that Size returns the em-size, which NinjaTrader_Dave says will be in device-independent pixels. What I am missing is how to get from knowing the em-size to knowing the dimensions of a text box containing a multi-line string.

--EV

[koganam]

What I care about is dynamically placing the text block so it does not obscure anything else. To do that reliably I need to now its size. I still do not understand how to do that.

• NinjaTrader_Dave suggests using the Text object's font.size property
• I do not see how to get a Text object prior to drawing, which is what I need in order to Draw at the correct location. The only way I see to get one is the result of a Draw operation. By then it is too late unless the idea is to Draw, cancel, and Draw again. Is that really what is being suggested?
• The documentation says that Size returns the em-size, which NinjaTrader_Dave says will be in device-independent pixels. What I am missing is how to get from knowing the em-size to knowing the dimensions of a text box containing a multi-line string.

--EV

You are not drawing a text box: you are drawing text. Granted that the text is in an enclosing box, that depends on both the font size and kerning. Trying to get the size of the enclosing box seems to me to be overthinking the matter. Draw.Text() has an overload to precisely position text as an offset to the anchor. The space occupied by multiple lines is just the number of lines multiplied by the font height. If you want to add some space, specify it by pixels.

[ETFVoyageur]

You are not drawing a text box: you are drawing text. Granted that the text is in an enclosing box, that depends on both the font size and kerning, trying to get the size of the enclosing box seems to me to be overthinking the matter. Draw.Text() has an overload to precisely position text as an offset to the anchor. The space occupied by multiple lines is just the number of lines multiplied by the font height. If you want to add some space, specify it by pixels.

I know it is not a text box, in the sense of a TextBox control, but whatever you want to call it there is a visible rectangular area consumed (with background and/or outline showing). I am trying to position that rectangular area relative to chart bars and/or the cursor position. As to position relative to the anchor -- I am using Draw's Y pixel offset. I had not thought about looking into the Anchor itself. Should I be using Anchor.MoveAnchorX() and Anchor.MoveAnchorY()?

As you state, the exact dimensions of the rectangular area depend on things I cannot reasonably know or compute, which is why the Text thing-y (technical term) should provide that information.

As to height -- that was confusing. The Text documentation links Font to an MSDN web page, which says that Size "Gets the em-size of this Font measured in the units specified by the Unit property". I don't know how to convert that to a height, but there is also a Height property, which sounded promising "Gets the line spacing of this font".

In fact, though, the web page link should not be to that MSDN Font page. The Font we are using only has Size (per Intellisense). When I looked at that value, it seemed to be about a line height, so I went with that. Multiplying that by the number of lines does not give a big enough height, though -- presumably due to spacing between lines and perhaps a top and bottom margin. I added a 2 pixel fudge factor to the "line height" and it is working pretty well now -- at least for my screen.

Furthermore, none of the above addresses the width of the text area. I wanted to prevent drawing off the left edge of the screen so I ended up resorting to a heuristic -- if drawing relative to one of the 10 left-most bars assume that off screen may be a problem and adjust accordingly.

As you can see, I have had to resort to heuristics (i.e. kludges) that may or may not be portable. While I do not plan to make a cause out of this, it does seem to me to be sub-optimal.
=====

The other thing I have noticed is that I am drawing near the cursor and there is a quite perceptible delay (fraction of a second) which is disconcerting. If this were a commercial product I would expect customer pushback that the text does not smoothly track the cursor. I have not yet made any attempt at understanding the performance. I therefore have no opinion on whether it is a Windows issue, an NT issue, or something I should be doing differently.

--EV

[koganam]

I know it is not a text box, in the sense of a TextBox control, but whatever you want to call it there is a visible rectangular area consumed (with background and/or outline showing). I am trying to position that rectangular area relative to chart bars and/or the cursor position. As to position relative to the anchor -- I am using Draw's Y pixel offset. I had not thought about looking into the Anchor itself. Should I be using Anchor.MoveAnchorX() and Anchor.MoveAnchorY()?

As you state, the exact dimensions of the rectangular area depend on things I cannot reasonably know or compute, which is why the Text thing-y (technical term) should provide that information.

As to height -- that was confusing. The Text documentation links Font to an MSDN web page, which says that Size "Gets the em-size of this Font measured in the units specified by the Unit property". I don't know how to convert that to a height, but there is also a Height property, which sounded promising "Gets the line spacing of this font".

In fact, though, the web page link should not be to that MSDN Font page. The Font we are using only has Size (per Intellisense). When I looked at that value, it seemed to be about a line height, so I went with that. Multiplying that by the number of lines does not give a big enough height, though -- presumably due to spacing between lines and perhaps a top and bottom margin. I added a 2 pixel fudge factor to the "line height" and it is working pretty well now -- at least for my screen.

Furthermore, none of the above addresses the width of the text area. I wanted to prevent drawing off the left edge of the screen so I ended up resorting to a heuristic -- if drawing relative to one of the 10 left-most bars assume that off screen may be a problem and adjust accordingly.

As you can see, I have had to resort to heuristics (i.e. kludges) that may or may not be portable. While I do not plan to make a cause out of this, it does seem to me to be sub-optimal.
=====

The other thing I have noticed is that I am drawing near the cursor and there is a quite perceptible delay (fraction of a second) which is disconcerting. If this were a commercial product I would expect customer pushback that the text does not smoothly track the cursor. I have not yet made any attempt at understanding the performance. I therefore have no opinion on whether it is a Windows issue, an NT issue, or something I should be doing differently.

--EV

Draw.Text() in particular (and also the ONLY NT Draw() method) has an overload to precisely position text, to pixel level offset precision. Heck, the parameter is even called yPixelOffset in the code signature.

I have made multiple requests to have that same precision-positioning overload applied to all DrawObjects, but the suggestion appears to have not made it to the "important" development assignation yet.

I would not be surprised if my requests are the only ones on the matter, as it seems that kind of precision is not important to most people. Sorry that you and I are so anal-retentive about our code.